k33bz wrote in Wed Aug 28, 2013 12:53 am:With that in mind, I will just delete everything I just got from git fgdata, and move my backup files back in place then.
I wouldn't delete things yet, just rename the folder - so that you can reuse it, once you decide to use the latest version from git, which saves you tons of time and bandwidth.
However, quick question, I understand the backwards compatibility issue, lol, even the part you said todays newspaper not being able to be in archives of a few years back.
Ya, I am known for my colorful analogies that are intended to be fool-proof
But my question is, if the git file on gitorious is development (which is constantly improving) why is it at version 2.99, and not version 2.11 or 2.10.4 or something that is above the current release?
see the release plan:
http://wiki.flightgear.org/Release_Plan#Version_numbersbasically: 99 is greater than 10, than 12
(Which is why I probable assumed that the core itself is the same because of those things I am asking about)
It's a known issue, we are hoping to fix the versioning scheme after 3.0:
http://wiki.flightgear.org/Release_plan ... arned#2.12 (see the versioning sectoin there)
Version numbering:
There was already a couple of people on IRC confused that 2.12 is different to 2.1.2 (since minor version numbers > 9 are something of a rarity in many people's perception).[4]
— James Turner
Give our release pattern is date scheduled, an Ubuntu style numbering scheme would actually make more sense, but a bit more effort to move too.[5]
— James Turner
Externally, 3.0 is going to be considered a bigger deal than 2.12.0.[6]
— Stuart Buchanan
I suggest that we zero-pad the minor release digit after 3.0.0 so we have 3.02, 3.04 etc. to reduce confusion if we reach double digits.[7]
— Stuart Buchanan
many computer systems sort file names in ascii order, many people don't seem to pay careful attention to where the decimal points are placed, etc. Once we clear past the 2.10, 2.12, etc. series, I'd like to go back to keeping things single digits in the major and minor version numbers and when we run out of a single digits bump up the major number (so 3.8.x -> 4.0.x). Number are numbers, but this one confused a lot more people than I expected it would or should so maybe it's good to be sensitive to that after we clear the 2.x series of versions.[8]
— Curtis Olson
That sounds OK to me, as it would imply a full release every 2.5 years, give a clear flag ahead of time when we're nearing a major release, and save having these discussions in the future. For reference, with the current plan there will be 4 years between 2.0.0 (Feb 2010) was and 3.0.0 (Feb 2014). [9]
— Stuart Buchanan
I've set the version files on 'next' to be 2.99, on the assumption the next release will be 3.0 as discussed.[10]
— James Turner