* Luke Gorrie luke@bluetail.com [2004-06-30T00:12+0200]:
I checked in a mkdist.sh shell script for creating a distribution. I made a "fake" release called 1.0alpha0 with it here:
FWIW, I do not like such kind of version numbers much. There are a small to medium pain for package maintainers ("Is '1.0' newer than '1.0alpha0'?"), and otherwise do not carry other information (I could expand this last point to a multi-page rant on request, but I count on common sense and general experience with software telling the same). There are enough "1.0" examples out there which are everything but stable, after all.
In short, I would like to propose a compromise versioning scheme, namely the "n_1.n_2.\dots.n_m" format.
Rationale: It still carries some hints^Winformation for users (mainly the (subjective) "graveness" of changes: major, minor, etc.), but is easy to grok for computers (which should be the main reason to use it), can be split into its hierarchical parts easily, etc.
Example (with m=3, can be expanded if needed): So, I would label the release candidate "0.9.0", following bug-fixed versions would get "0.9.1", "0.9.2", etc. and once everyone is happy with it for a while, release it as "1.0.0". After that, immediately switch the unstable/currently-being-hacked-on/CVS version to "1.1.0", and start adding features. Backporting features/bugfixes would result in "1.0.x" releases, the next bigger releases would be called "1.2.0", and the hacking branch would be switched to "1.3.0" simultaneously. When ;) SLIME gains self-awareness, you as well could call it "2.0.0"...
Summary: A version x.y.z * with (evenp y) means "stable"/released version * with (oddp y) means hacked-on version, not "officially" released, might be broken * with (plusp z) means minor fixes/backport of changes relative to "x.y.0"
For users who know, the version numbers convey some information, for users who don't, it does not matter (they will pick the newest released one) and for computers/programs this format is easy to handle.
I would also advise to use "x.y.0" and not contract it to "x.y", again for reason of simplicity in case a program needs to parse the version number for some reason (yes, I do know the credo "test for features, not for a version", but still it might be needed).
I have been through this a couple of years ago with Glasgow Haskell Compiler head quarters (version numbers used to be a pain there, too), and the above described scheme now works well, I think (haven't heard complaints, at least). Of course, it was introduced too late and the damage was already there (just have a look at some shell scripts which parse ghc version information).
Anyway, the above story just reflects my experience, feel free to ignore me. :)
Cheers, Michael