"Daniel" == Daniel Reed <[EMAIL PROTECTED]> 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-9bIn 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__/_______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
