Johan G wrote in Wed Nov 06, 2013 12:15 am:I have planned to be able to have all stable versions past 2.0.0 installed at some undefined point in the future. The reason to have them all would be to able to try understand the differences and pitfalls in trying to get aircraft flyable on all versions.
=> new features, and changes in old ones.
Unfortunately it seems less and less practically possible, which quite make me understand the current situation where most aircraft developers expect the users to have the latest stable version (or even sometimes the bleeding edge GIT).
(It's not your fault in particular though, I'm just venting some steam...)
It's actually a good thing, because it means that core development is making progress - the real issue here is that there's no conscious effort to prevent breakage, i.e. by maintaining a minimal degree of backwards compatibility. Basically, we shouldn't be removing/renaming features (think APIs), but rather provide migration layers for 1-2 release cycles - obviously, it takes more time to implement such layers that translate new features into APIs understood by aircraft that haven't been updated.
Honestly, the way aircraft development is conducted, it is challenging to accommodate such needs - because, it's also not possible to maintain/update aircraft in a semi-automated/scripted fashion, due to their arbitrary internal structure, empowered by XML, the property tree and scripting.
At the end of the day, it's really up to aircraft developers to keep things up-to-date for different versions, that it's possible can be seen in examples like the bluebird - whose author/developer seems aware of major changes between different releases, and puts a conscious effort into abstracting away differences by using different *-set.xml files for different FG versions, and including shared/common stuff from there on. There's something to be learnt from such examples. But obviously it takes more time and energy to do this type of work, no matter if it's maintaining different -set.xml files for various FlightGear versions, or maintaining a certain degree of backwards compatibility in the core. In the end, time is a precious resource and we cannot expect people to find it more interesting to guarantee backwards compatibility, than working on new features. It can however, as could be seen in Thorsten's weather package or flug's bombable addon - both being much more complex and sophisticated than your average aircraft, but both "addons" supporting a wide range of FlightGear versions (up to a point), due to conscious design efforts.
But please don't expect 2013-era aircraft like the 707 to work in FlightGear 1.9:
Subject: Citation X CVS to FG 1.9.1Hooray wrote:Quoting myself:
http://flightgear.org/forums/viewtopic. ... ity#p95615Hooray wrote:This is not at all about "backward compatibility" - what you are asking for is sort of "forward compatibility".
What you have basically done is creating a document in "Microsoft Office 2010", and now you expect to be able to open this document in "Microsoft Office 97".
This is of course not possible. You have used new features that didn't exist in previous versions of FlightGear - FlightGear is improving, and you are basically complaining about the fact that these new features were not yet available in prior FlightGear versions.
Backward compatibility is about supporting features of past software versions in new/future versions. You are asking for the reverse.
To explain this even more bluntly: If users started to use YOUR aircraft now with FG 2.0, they would probably complain that YOUR aircraft was not implemented with backward compatibility in mind - simply because your work doesn't work with older FG versions.
Weird world, isn't it
We should probably copy this to the FAQ?
Thorsten wrote in Mon Dec 17, 2012 8:42 am:I use Ubuntu 10.04 because of the long term commitment to support for this version, I have flightgear 2.4 and find now that most developments eg aircraft etc are not backward compatible, ie a330-200 series doesn't work and many other things
I don't think that's a particularly fair thing to ask, and I don't think you can run FSX airplanes on Microsoft FlightSim 8 (which is the proper comparison).
FG is (in a limited way) backward compatible in such that a 2.9 binary runs many airplanes which have been released with 2.4. What you're asking however is forward compatibility, i.e. a 2.4 binary should be able to run airplanes for future releases - and that's just impossible to do.
New airplanes rely on new features present in the binary - for example a lot of MFD and HUD technology is now being built around canvas. Cavas doen't exist in 2.4, so there is no way this can be supported properly, even if we wanted to. If you have 2.4, you'll need to use airplanes released for 2.4.
We should probably add this in some way to the wiki, because it seems to be a rather common complaint:
http://flightgear.org/forums/viewtopic. ... ty#p148559That said, some aircraft are obviously developed with backward compatibility in mind, such as the bluebird and a handful of others which provide different versions for different FG binaries. But like Thorsten said, this is only to a certain extent possible - and it is obviously a lot of work for the aircraft developers. Flug's bombable addon is another excellent example of an addon that is developed in a fashion to retain backward compatibility with earlier FG versions, and Thorsten's local/advanced weather systen is another example actually. However, this is obviously only possible to a certain degree. For example, Tom's canvas system is also being developed such that backward compatibility is an explicit design feature, yet - you will obviously need a binary that provides the canvas system, despite all the Nasal-space wrappers...