[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Version numbering

From: Howard Chu
Subject: RE: Version numbering
Date: Tue, 30 Sep 2003 01:59:13 -0700

> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden Behalf Of Bernd

> Hash: SHA1
> On Tue, Sep 30, 2003 at 09:33:29AM +0200, Alexandre Duret-Lutz wrote:
> > Obviously, as long as characters are reserved for beta releases,
>                                                     ^^^^^^^^^^^^^
> > we may not care about such installation tools.  After all the
> > real releases are easy to sort since they use only digit.
> > As far as explaining the new scheme is concerned, I claim that
> > it's easier to do if it works with `ls -v'.
> Zack Weinberg seems to have spent a lot of thought on version
> numbering:
> > In the past, people have also argued that using characters was
> > making it more difficult for tools to sort the versions.  If you
> > agree you might as well switch to the blessed FSF way of making
> > beta releases (using .90, .91, .92, etc.).  Texinfo and
>  From zw's page:
> Now, some of the numerous ways to do it wrong:
> ...
> 7. The  GNU  maintainer  advice for test releases has an especially
>    pernicious suggestion, to use 4.5.90, 4.5.91, ... for test releases
>    up to 4.6; not only does this clash with the namespace of
> patchlevel
>    releases (what if there really were 90  patchlevels to  4.5?)  but
>    it  continues  by suggesting that the sequel to 4.5.99, if
> you're not
>    done, should be 4.5.990, which is just plain wrong. See above about
>    version numbers not being decimal fractions. Taking this
> advice is a
>    common error.

Just as another data point, on the OpenLDAP project beta releases have no
special numbering, they are just another patchlevel, with an optional
(qualifier) appended (e.g., 2.2.0alpha, 2.2.1beta) but the qualifier is not
part of any filenames anywhere - it's just 2.2.0 and 2.2.1. The first
official release of OpenLDAP 2.1 was 2.1.2. I personally hate the additional
letters/suffixes whatever because it is extremely confusing to determine if
4.5j comes before or after 4.5.

You folks are talking about qualifiers being used for pre-release code, while
the OpenSSL project is a conspicuous example of the opposite - 0.9.6j is much
newer than 0.9.6, and 0.9.7b is newer than 0.9.7. At least their scheme sorts

In a perfect world I'd go with major.minor.XXX and make the patchlevel a
genuine decimal fraction: .001 - .999. If you make more than 1000 patches to
something you really ought to consider calling it at least a new minor
release. For my own use I'd be happy with hexadecimal; again if I'm
packaging 255 patches to a release I think it deserves to have a new release

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun     
  Symas: Premier OpenSource Development and Support

reply via email to

[Prev in Thread] Current Thread [Next in Thread]