On Friday 16 Oct 2009, Martin Spott wrote: > leee wrote: > > I think you need to accept that many aircraft are indeed > > broken, and most have been broken by software changes made > > since the aircraft was released. > > No, I don't have to.
Well, I'm afraid that you're in denial then. > I _do_ accept that some aircraft developers are a little bit > lazier than others and don't care about maintaining nowadays what > they have contributed formerly. I also do agree that those who > are maintaining FDM updates are unable to forward-port every > single hack in aircraft configurations - even though most of them > typically try to catch as many of them as possible. > But, hey, this is open source, some players simply respond and > proceed quicker than others do. > > > Sadly, while no consideration is given to backwards > > compatibility i.e. by allowing different versions of > > sub-systems to be used by specifying a version in the > > appropriate config file, broken aircraft will remain a feature > > of FG. > > Instead of pouring time into a (probably) never ending chain of > backward compatibility (alias "old cruft") layers, I think the > effort is much better spent for bringing the respective aircraft > configurations onto speed for FlightGear's current capabilities. > > Cheers, > Martin. Can you not see the self-contradiction in what you've written? You're claiming that compatibility is purely an issue for aircraft developers, and not for software developers? Your assertion that aircraft developers are simply too lazy to spend all of their available time fixing problems caused by the software developers is simply insulting. Sadly though, I think that was your intention. Your objections to incorporating backwards compatibility in the software are similarly distorted and exaggerated. Backwards compatibility need not require time to be 'poured' in to it and doesn't mean a never-ending chain of 'cruft' layers. First of all, if something is being used then it's not cruft (although I can see how a lazy software developer could describe it as such if all they're interested in is new shiny stuff). Secondly, never-ending backwards compatibility is not a requirement and at most, only two or three versions might be needed as I think it would be reasonable to drop +2 old versions. Thirdly, providing backwards compatibility would be fairly trivial and need not require lots of time as there's no intrinsic problem with including several different versions of a module, with the appropriate one being selected at run time, via a config parameter. Perhaps some developers are just too lazy to add a new module though, when they can just hack into the existing one, especially when any breakages this may cause are the responsibility of those lazy aircraft developers anyway. I'm afraid that I just couldn't parse "I think the effort is much better spent for bringing the respective aircraft configurations onto speed for FlightGear's current capabilities". But then I am (was) just a lazy aircraft developer who found that I had no time to work on new stuff because I was spending it all on fixing problems caused by developers who, curiously enough, seem to have no time to avoid or fix those problems because they only have time to work on new features. LeeE ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
