sbook said:
.... now just for clarification, but is the popular way of doing things?
X.X.EvenNumber = stable
X.X.OddNumber = test release
No, not "popular", but there's nothing wrong with using even/odd to denote stability, though it wouldn't work exactly as you present it. Assuming you are going with 3-segment version labels (a.o.t. 4-segment), we have MAJOR + MINOR + BUILD. Purpose and usage of the last segment varies and is often called, ambiguously "revision" or "version"-- for concreteness, I'll call it BUILD. If you're going to denote stability with an even number, you can't use the BUILD segment for that, which needs to increment within the MINOR series. Using the Linux kernel as an example, 2.3 is an unstable MINOR series which must use even and odd numbers to distinguish BUILDS, like 2.3.0, 2.3.1, 2.3.2... (FYI, the latest Linux kernels are using 4-segment labels).
The only thing with all of it that's really counter-intuitive and pretty non-standardized is that longer version labels generally precede shorter version labels chronologically. For example, if you are working towards a 2.4 release, the chronological sequence may include, in this order: 2.4.0,... , 2.4.2bSNAPSHOT,..., 2.4.2b, 2.4.2,... 2.4. Fortunately, there is consistency in that if one distro label starts with the entirety of another, the shorter is always the more stable. For example 3.4 will always be more stable than 3.4.anything, regardless of chronological order.
Everybody has their opinion about indication of sub-build distinctions. I'll tell you my personal preference. I think that using a consistent and meaningful suffix to the build segment is more immediately and intuitively understood than using a 4th numerical segment. Suffixes to build segments indicates less stability. Example, in chronological order:
2.0.2b2SNAPSHOT = a snapshot. Non-stamped snapshot files like this are understood to allow updating without changing the file name.
Non-stamped snapshots are a good option for nightly builds where you don't want to archive but just to overwrite every night.
2.0.2b2-20090908a OR 2.02b2-SNAP20090908a = a snapshot with a distinctive name
(don't have to worry about overwriting, and the label gives useful info useful for leading edge developers.
may also make sense to use svn revision instead of date here).
2.0.2b2 = beta #2 in preparation for public 2.0.2 release
2.0.2 = public 2.0.2 release