[Top][All Lists]

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

Re: Version numbering

From: Gary V. Vaughan
Subject: Re: Version numbering
Date: Tue, 30 Sep 2003 13:20:22 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20030925 Thunderbird/0.3

Alexandre Duret-Lutz wrote:
"Daniel" == Daniel Reed <address@hidden> writes:


 Daniel> Several GNU projects (including GCC) do leave off .0's
 Daniel> for anything past the minor number, so it seems ls -v
 Daniel> can't be the final authority :/

Sorry I meant to compare only the version numbers not the full filename.

That doesn't make any sense. Why would you create a bunch of files named with just the version number in order to figure out what order a bunch of other files were released in?

Comparing version number is what automatic installation tools
has to do in order to know which version is newer than the
other.  Such tools can deal with 1.2 being older than 1.10, but
they have trouble realizing that 1.3pre2 before 1.3 is know to
break them, because 1.3pre2 is lexically after 1.3.  Debian at
least has a special workaround (the maintainer of a package
add a extra digit in front of the version number) to cope with
such unsortable numbering scheme.

I agree with this.

Hence the suggestion of supporting at least `ls -v'.

% ls -v1

And in principle I agree with this. But you can't use `ls -v' to sort version numbers; it will only sort files.

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'.

Ah, maybe this is what you meant all along? And you don't mean to actually use `ls -v' to sort the version numbers...

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
Coreutils switched to it recently.  I don't really like it
because I think it's horrible with branches and is less obvious
than characters (I really like these extra characters).

Yes, me too. On all counts. Actually, I started thinking about this in terms of tagging CVS rather than naming release tarballs.

A scheme which I think would be compatible with Gary's will
(maybe this is what he proposed, I simply did not understand
whether he wanted to jump from 1.7d down to 1.7 or up to 1.8).

    1.6 (release)
1.7a (CVS), 1.7b (beta), 1.7c (CVS), 1.7d (beta), 1.8 (release)
on the branch:
    1.8.1a (CVS)
    1.8.1b (beta)
    1.8.2 (release)

etc.  Keeping odd version for development ensure people cannot
mis-sort versions with letters with others. It could also gives
some feeling of sense to accustomed to the odd/even version
numbering scheme of Linux.

I like this idea!  But it doesn't solve all my issues...

The criterion I want to satisfy are:

 1: alpha releases, point releases, and patch releases should be
    visibly different to one another.
 2: release branches and development branches should not lead to
    the same (or even similar) version numbers to HEAD or each
 3: it should be easy to tell whether you are running a self
    built CVS snapshot, or an official release.
 4: the system should be easy to understand in terms of which
    releases are `newer'.
 5: it shouldn't be too different to what we have now.

How about this:

    +----------> branch names
    |       HEAD          branch-1-5       branch-1-6       branch-1-8
    |       ====          ==========       ==========       ==========
    |                   release-1-5-0
    |     release-1-6b
    |     release-1-6d
    v                   release-1-5-2
tag names               release-1-5-4
 (time)   release-1-6f
                          *CLOSED*          *OPENED*
                                            *CLOSED*         *OPENED*

In relation to the points above:

  1: Yep.  Alpha's have a letter, point releases have no micro version,
     patch releases have even minor and micro versions.
  2: Check.  We have letters in HEAD releases, and branches use the
     unique part of the branch name as a version prefix.
  3: Uh-huh.  We'll keep using `odd' letters for versions between
     official releases.
  4: Definitely.  If it is lexically higher, it has had more development.
  5: True.  Apart from more unused revision numbers, everything looks the

On release branches, we need to avoid the same problem in the micro revision as we have solved for the minor revision. So we use 1.6.1a/b etc. in AC_INIT
between 1.6 and 1.6.2 -- historically we haven't released alpha's from
a release branch, because they are feature frozen.  However if we did, we
can't choose something that is obviously between 1.6 and 1.6.1, so we can
only release even numbered micro revisions.

How's that?

  ())_.  Gary V. Vaughan    gary@(|
  ( '/   Research Scientist       ,_())____
  / )=   GNU Hacker  \'      `&
`(_~)_   Tech' Author   =`---d__/

reply via email to

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