Re: Version numbering

[Gary V. Vaughan]

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
> 1.5
> 1.5.0a
> 1.5.0b
> 1.5.1
> 1.5a
> 1.5b
> 1.6
> 1.10

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
    other.
 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
                        release-1-5-6
                          *CLOSED*          *OPENED*
                                          release-1-6-0
          release-1-7b
                                          release-1-6-2
          release-1-7d
                                            *CLOSED*         *OPENED*
                                                           release-1-8-0
          release-1-9b


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

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?

Cheers,
        Gary.
--
  ())_.  Gary V. Vaughan    gary@(lilith.warpmail.net|gnu.org)
  ( '/   Research Scientist http://www.oranda.demon.co.uk       ,_())____
  / )=   GNU Hacker         http://www.gnu.org/software/libtool  \'      `&
`(_~)_   Tech' Author       http://sources.redhat.com/autobook   =`---d__/