Release plan for 2020 / LTS
| This article is a stub. You can help the wiki by expanding it. |
1) Make a 2020.1 unstable release (aka ‘LTS preview’) in a few weeks time. The upcoming stable FG release (2020.2) still works with CMake 3.0 [1] 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(likely to be postponed as per [2] [3]) (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.
So a key feature of the LTS approach, especially the fact that we branch FGaddon, is that if some collection of people decide running 2018.3 is more beneficial to them than some newer version, they can do it fairly easily: for the next while we can still build it ourselves, and it wouldn't be especially hard to fork it into a ‘Flightgear-2018-Forever’ if someone cared. (At some point it will become hard to build the code, since it will depend on SDKs / compilers which are hard to track down, but, well, that’s the problem for those people to figure out, I guess)[4]
FlightGear is not an application, it’s an SDK. The reason the above doesn’t work, especially the quarterly releases, is not about the code quality per-se, but rather about aircraft compatibility. We don’t do LTS for the sake of fixing a random bug in the UI, we do it so end-users can have an expectation of particular aircraft they downloaded from $random-website working or not working. And we have no control over aircraft developers, and often not much contact with them. It’s Long-term STABLE, not Long-term SUPPORT, even if we do some support to be nice.
So part of the idea of the LTS (from my side) is to have a setup where flight-simmers understand that just because their plane worked in Xplane 10, doesn’t mean it will work in Xplane 11: and therefore just because it works in FG 2018.3, does /not/ mean it will just work in FG 2020.2, at least without checking. (And we should make the checking process accessible and community driven - hence the ‘aircraft testing’ stuff we’re trying to encourage right now)
Hence the long release cycle: it’s not actually about fixing core bugs (although that will be nice, to focus people’s attention on bugs rather than new features….), it’s about checking aircraft and giving a stable and compatible platform. [5]
Compositor
|
|
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.[6]
Worth pointing out that we did something broadly similar in the past when
we introduced OSG, so we should embrace this rather than being worried
about making drastic changes.[7]
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.[8]
Publicity
we could suggest that aircraft maintainers concentrate only on the stable-2020, and the core developers put extra effort into documenting the incompatibilities and migrations required. That way when next is feature-complete and stable with the new changes, we can provide high quality instructions to aircraft maintainers to do a migration of their aircraft.[9]
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.[10]
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)[11]