version numbers (was: Re: [slime-devel] The 1.0-alpha plan)

[Michael Weber]

* Luke Gorrie <luke at 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