Release plan for 2020 / LTS: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
m (→‎Compositor: https://sourceforge.net/p/flightgear/mailman/message/36974362/)
m (→‎PR: https://sourceforge.net/p/flightgear/mailman/message/36975121/)
Line 39: Line 39:


Contents: https://sourceforge.net/p/flightgear/mailman/message/36974362/
Contents: https://sourceforge.net/p/flightgear/mailman/message/36974362/
== Publicity ==
the ‘publicity’ around this would be:
* you can use 2018.x ‘forever’ if it works for you
* once 2020.1 is created, people should test aircraft using it and report bugs, since it will represent the feature-set for 2020.2, aka the new stable release
(this is also already true of 2019.1.)
After the 2020.2 branches exist, everyone should focus on that in terms of testing and quality, and since next will likely be a bit of a mess. (It might even make sense to make nightly builds to build from 2020.2 branch, until 2020.2 is released)<ref>https://sourceforge.net/p/flightgear/mailman/message/36975121/</ref>


== References ==
== References ==
{{Appendix}}
{{Appendix}}

Revision as of 15:35, 8 April 2020

This article is a stub. You can help the wiki by expanding it.

Will need to summarize the discussion at [1]

1) Make a 2020.1 unstable release (aka ‘LTS preview’) in a few weeks time. This will contain some known issues of course, eg texture-cache issues on macOS, the Shuttle Nasal bug, etc. But it should also have working

  • a Windows Compositor build in the installer (thanks to some work by Jonathan R)
  • Swift on macOS
  • some new launcher options (carriers, favourites)
  • likely a bunch of other smaller stuff I forgot, we need to make an actual changelog

The default airport for this release with be BIKF.

2) Some time ‘not long after’ 2020.1 is released, we will make the release branches for 2020.2, which will become the LTS release. The target release date for this will be quite a long way out : at a guess, sometime in September. The idea being we have a very long period of time to chase down the Shuttle Nasal bugs, hopefully fix the texture-cache issues so that it can be enabled by default, update translations, and so on.

IMPORTANT As part of this, we will also make a branch in FGAddon (’stable-2020’), so that aircraft can be stabilised targeting the 2020.2 feature-set. 3) Once the 2020.2 release branch is created, we can start making some more drastic changes on ‘next': in particular I would propose

  • make Compositor the default, and then, the only, renderer (i.e remove ‘classic’ and Rembrandt)
  • make ALS the default effects pipeline
  • drop 32-bit Windows support
  • switch to C++14, because it’s nice and cool :)
  • remove any other legacy things people wish to suggest: eg remove legacy joystick code in favour of HID, remove the legacy HUD code, figure out what to do with the 2D panels code.

Basically, to use the post-LTS time to drop various legacy and unmaintained pieces, and reduce the number of configurations that have to be tested / developed. Of course we’re not committed to doing /any/ of those changes, but it would be the obvious time to introduce high-risk and incompatible changes.

Goal

The goal here is : deliver a stable 2020.2 which aircraft developers can develop aircraft against for the next 2 years (or more...). It should be clear from this plan that after we branch for 2020.2, most people who want do any actual flying (or indeed, testing, or aircraft development) should be using the stable branch. This does mean that 2020.2 with be the last release to support Rembrandt, and the last 32-bit windows release.

It’s worth noting that thanks to Jenkins, within reason we can continue to make LTS releases of 2018.3 or 2020.2 ‘forever' - if for example someone is really in love with Rembrandt, there is nothing to stop us (or them) making a 2020.2.42 release in eight years time, for their 32-bit Windows 7 install, to fly their favourite Rembrandt aircraft :)

We will need to ensure that aircraft developers using FGaddon understand that the stable-2020 branch and trunk really will be incompatible : we do have the official policy that we don’t support try to maintain compatibility for older aircraft in new releases, and here we absolutely meant it. No one should be expecting, or trying to, make an aircraft compatible with both. But I’m not sure how best to communicate that, suggestions appreciated.


Compositor

1rightarrow.png See Compositor for the main article about this subject.


Contents: https://sourceforge.net/p/flightgear/mailman/message/36974362/

Publicity

the ‘publicity’ around this would be:

  • you can use 2018.x ‘forever’ if it works for you
  • once 2020.1 is created, people should test aircraft using it and report bugs, since it will represent the feature-set for 2020.2, aka the new stable release

(this is also already true of 2019.1.)

After the 2020.2 branches exist, everyone should focus on that in terms of testing and quality, and since next will likely be a bit of a mess. (It might even make sense to make nightly builds to build from 2020.2 branch, until 2020.2 is released)[2]

References

References