I-NEMO wrote in Sat Dec 12, 2015 5:49 am:Regarding the Standard: I remember a post exchange with Hooray some time ago, where I pointed out that in my opinion FG lacks a stable Standard.
Let me explain: of course the Core code side always tries to enhance performance and new opportunities.
That's absolutely correct, so to ensure technical growth of the whole platform.
I still think, though, that an effort to have stable versions, and a sort of fair calendar so that other people might have time to adapt the existing model to the new opportunities offered by the technical growth should be considered a priority for a proper overall growth of the FG Simulation platform.
[...]
Sometimes too much 'coding' is required in order to see the model flying again in the new framework updated to the latest technical standpoint. Which, in turn, makes the aircraft's fleet completeness erratic; sometime a model just lies abandoned, for several reasons.
We do grow, but sometimes in too wild a grow.
That's a key factor to ensure FG a consistent fleet of models (complete models, as I wrote above) flyable (I mean enjoyable) in a better technical framework.
I do remember that exchange, but I don't think I agree with you - simply because of the circumstances at hand: Basically, all FlightGear core developers agree that they are overstretched in terms of their responsibilities and workload - realistically, FlightGear is not seeing that much change in comparison to past times. The number of active core committers is remarkably low, and the number of patches that don't even make it into FlightGear clearly shows that there isn't too much being changed currently.
Under different circumstances, standardization would be a really good thing - which you can see by looking at other, more successful, open source projects and their efforts to introduce/maintain "long-term-support" (LTS) versions/distributions.
But with FlightGear, the challenges are hugely different, it does not make sense to focus too much on backward compatibility, or even release plans/roadmaps, given the very real constraints the project is facing.
A "stable" FlightGear version would be hugely frustrating for all the parties involved, especially end-users, who will want to use the latest/greatest features, despite not being willing to upgrade their hardware/system or even just FlightGear version. Just look at the number of threads where people wanted to run feature X (space shuttle, ALS, earthview, extra500, 777, Canvas stuff) with outdated FlightGear versions.
The whole thing would be reminiscent of the plib/osg migration process, where people (in fact, even core devs) began requesting certain useful changes to be "back-ported".
From a resource/manpower standpoint, that's simply not feasible given the challenges the project is facing.
The degree of changes the FlightGear core is seeing is not very much - if you are still concerned about those, it would be much better to get involved in testing so that you can provide timely feedback.
And in fact, many changes don't even involve the core (SG/FG) at all - i.e. backward compatibility is not just a core development issue, it can also be implemented by fgdata developers.
(Note that the release plan is in the process of being changed)