Release plan for 2020 / LTS

From FlightGear wiki
Jump to navigation Jump to search
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/

Compatibility

after 2020.2 is the right time to choose forwards compatibility over backwards compatibility. Especially if we can script it.

Essentially I’m assuming there will be enough divergence across the 2020 and following releases, that we’re better to take the hit and fix any structural issues we can, within reason. Ideally we will also end up with a ‘migrate_aircraft.py’ which can be trivially run on FGAddon to convert un-maintained / un-developed aircraft from 2020 to whatever changes are needed. But I think we’ll review that as the post-2020 features develop, and we see what things actually break, what can be kept working without compromising forwards compatibility, and so on. Maybe it ends up being quite minimal changes for many straightforward aircraft, which obviously would be ideal.[2]

Testing

the point of a point release is missed if the testing is done and results reported, but the reports are not followed up. And naturally the individual users reporting will over time stop that if nothing really happens in response - yet most bug reporters are not trained in diagnosing the issues they see to the end and can't deliver a useful report on their own.

With potentially more breaking changes coming, I'd strongly recommend to implement a procedure to systematically test what is broken and what not. We have currently no way to assess what part of the aircraft repository is still operational, and in my view such a thing would be badly needed.[3]

Publicity

At some point, it needs to be communicated to prospective users that 2020.1, and beyond, would be ideal for latest developments; whereas, 2018.3.5 might be advisable for legacy aircraft and older systems, with 2018.3.5 being retained as an alternative version for the foreseeable future.[4]

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)[5]

References

References