[Flightgear-devel] Releases

[James T. <ja...@fl...>]

Hello everybody,

(side note, hope you’re all doing okay in the current interesting times - for me it means for time for FG, but I can guess for others its the opposite, depending on child-care)

I'm going to be making an updated LTS release soon, since the current binary cause problems on macOS, and we (at least, thanks to painstaking work by Gene) have a stable macOS build slave again, running a very recent macOS build.

So this will be 2018.3.5.

As ever, if there’s other bug-fixes on the branches (I’ve seen at least one for JSBsim already included), or anything else (eg the C172P), they can still go into 2018.3.6 or whatever - now the infrastructure is running again, making builds is not hard. (If there’s a fix ready to go, I there is also time to get it into 2018.3.5, in principle, but I’m planning to press the button really quite soon)

Next, I propose to make an unstable release, partly to end the 2019.1 / 2019.2 confusion. So this would be 2020.1 - I think it can go out ‘whenever’, unless someone has a large change they want to land, because of:

Third, I’d propose to make the new unstable release a ‘pre-stable’ release, i.e once it’s done, to avoid adding big / risky features, so that we can make a new LTS release this year. This means stabilising:

 - the Texture-cache (and deployment around it, eg, adding NVTT to the Windows 3rdparty repo) - I’m working on this now, since on macOS it has some issues
  (we could always disable it on certain platforms, but I want to put some time into seeing if I can get it working consistently first)
 
 - any compositor changes, so the compositor could be available to users somehow? (But not quite sure how we would achieve this, suggestions welcome)

 - Jules’ View changes (I think this is mostly there, but probably needs more aircraft tested?)

- my Windows UTF-8 path changes

- freezing the UI strings so translators can sync up for the LTS release

- remaining pieces from the bug-hunt?
 
 - anything else I forgot?

As an example of what we wouldn’t *do*, I have been discussing with a few folks about moving the input code to use HID on all platforms (and remove the PLIB JS code) -  we would /not/ do for the LTS release, since it will likely disrupt some custom joystick configs. But of course, the new HID code could be included as an off-by-default feature of the LTS release, so people can test with it.

I am deliberately /not/ setting a date to make the LTS release, though ‘before FSWeekend’ would make sense [1], i.e approximately two years after 2018.3.  At some point we will branch FGAddon to make a stable Aircraft catalog for it : probably a few weeks in advance of the actual release. (Input on this welcome). And especially since people may have very limited free time this year, I don’t want to pick a date that adds pressure to people at a stressful time. Hence wanting to get a date in people’s minds now, so we have a longer (and hopefully more relaxed) stabilisation phase.

So short term things:

 - let me know any bug-fixes to include in 2018.3.x release(s)

 - let me know any restrictions / pending changes on making an unstable release ‘soon’ (in the next couple of weeks, unless someone knows a reason to do otherwise - eg they’re about to merge large feature XYZ which they want included in the LTS)

Longer term things:

 - does the proposed LTS schedule give sufficient time for landing any new feature and stabilising them? 

 - does it work for the C172 team?

 - anything else I forgot?

Kind regards,
James


[1] - modulo the 2020 ‘assuming FSweekend happens’ caveat