Subject: Re: Version numbering - msg#00181

Previous Message by Date: click to view message preview

Re: Version numbering

Alexandre Duret-Lutz wrote: "Daniel" == Daniel Reed <n@xxxxxx> 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__/

Next Message by Date: click to view message preview

Re: Version numbering

Dalibor Topic wrote: Scott James Remnant wrote: On Tue, 2003-09-30 at 09:31, Bernd Jendrissek wrote: On Tue, Sep 30, 2003 at 09:33:29AM +0200, Alexandre Duret-Lutz wrote: 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. Besides the Linux kernel, what *else* uses that odd/even numbering scheme? I have seen a couple, but I can't remember any now. GLib, GTK+, Gimp and GNOME (as well as many to most GNOME apps) spring immediately to mind. Kaffe uses the odd/even numbering now too ;) After the next cron web update, please read: http://www.gnu.org/software/libtool/contribute.html and give me your feedback... The updated page has a version number table near the top. -- ())_. 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__/

Previous Message by Thread: click to view message preview

Re: Version numbering

On Tue, 2003-09-30 at 10:15, Gary V. Vaughan wrote: > Alexandre Duret-Lutz wrote: > > I didn't understand your proposal, but I hope you are not > > planning to make 2.2 < 2.3a < 2.3. That would be counter > > intuitive. IMHO any numbering scheme ought to work with `ls -v'. > > Actually, that is what I'm proposing: I've had to explain it many, many > times > over the years, and people just expect to see alpha/beta releases named after > the final release they are heading towards. > > Your point about `ls -v' is a good one though. I'll put an extra `-' before > the letter: > Not sure whether it's a concern, but generally most packaging systems (RPM springs to mind) do not allow a '-' in the package's upstream version. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part _______________________________________________ Libtool mailing list Libtool@xxxxxxx http://mail.gnu.org/mailman/listinfo/libtool

Next Message by Thread: click to view message preview

Re: Version numbering

Gary V. Vaughan wrote: I think when we branch for a release (say the upcoming 1.6), version numbers in the branch should continue to be "1.6.<micro><alpha>?", but that the trunk should bump its minor number to make it clear the trunk is very different to the stable branch: "1.7<alpha>?". We would of course continue to use "odd" letters for CVS revisions, and "even" letters for alpha releases. Thoughts? Excellent! Peter