On Sun, 2009-12-13 at 19:07 -0800, S Andreason wrote: > Jacob Burbach wrote: > > Traditionally it is MAJOR.MINOR.PATCHLEVEL, definately more than a > > patchlevel thing, and way more than minor, so either 1.10.x or 2.x.x > > if your following that standard. 1.10 feels weird, > > Maybe it is wierd. > 1.9 is mathematically the same as 1.90 > 1.10 is less than 1.90 by any normal math or sorting formula.
Version identifiers are not numbers, they are often stored as strings, the period is just a delimiter. Software version naming schemes are many and varied, and once the marketing department get involved all reasonable and rational numbering schemes go out the window, hence we have Office 2003 that was released in 2004, Oracle 11g Application Server is actually 10.3.1 etc etc etc I used to work for a company called Digital Equipment Corp. the version identifiers were prefixed by a letter which indicated it's level of release (ie: was it a fully released product). Also the even numbered releases (eg: V1.2, V1.4, V2.2, V2.4, V2.6) were for new feature releases, the odd numbered ones where mainly for bug-fixes. So a bit of code could started life with the letter 'X' for experimental,or just start with 'T', then when it was doing an internal beta (field) test it started with 'IFT' or 'EFT' if external customers involved, and then finally the letter 'V' once customers could pay for it. There were a few other letters at various stages of release, but I can't remember them all. The version number part was major.minor and then if there was a patch that was added after a hypen, and then sometimes an update to a patch with a single letter (ie: A then B, then C etc) and also for some software there was a Baselevel number, the baselevel was a grouping of functionality, so for example you have some software where there is a slow meeting of functionality over actual version releases (for example the Route Manager/GPS code could release a base level of functionality for 1.10.0 and then more functionality for 1.12.0 and then even more functionality for 2.0.0, so these could be marked with BL1, BL2 and BL3) So versions would like; V1.1 T2.0 BL2 IFT1.3-5 Generally a major version number change is only for architectural changes, rather than the level of completeness, so we could have gone to V2.0.0 when moving from PLIB to OSG, even though all the functionality wasn't implemented, and you may well reach the level of all functionality being implemented in V2.5.0 and then moving V3.0.0 once it was stable. Some folks change the major version number once they have actually implemented the functionality they set out to implement in hand full of version changes (eg: V1.0, V1.1, V1.2, V2.0, V2.1, V3.0 etc). There is really no hard and fast rules, but you should be consistent to help users understand what they can expect in a release of software, small changes, big pain, new features, it also helps to work out dependency, V1.10.0 requires Foobar V3.9.0. Anyhow I vote for V1.10.0 it makes sense, to stay consistent, since it didn't go to V2.0.0 with the architectural change to OSG. S. ********************************************************************** This message is intended for the addressee named and may contain privileged information or confidential information or both. If you are not the intended recipient please delete it and notify the sender. **********************************************************************
------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev
_______________________________________________ Flightgear-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/flightgear-devel
