[PATCH 1/6] maint: copy the Version Numbering section into README.alpha.
* README.alpha (Version Numbering): No less useful for users of alpha releases. Copied from README. --- ChangeLog|6 ++ README.alpha | 56 2 files changed, 62 insertions(+), 0 deletions(-) diff --git a/ChangeLog b/ChangeLog index d72d9e0..3e1cb95 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,9 @@ +2010-09-18 Gary V. Vaughan g...@gnu.org + + maint: copy the Version Numbering section into README.alpha. + * README.alpha (Version Numbering): No less useful for users + of alpha releases. Copied from README. + 2010-09-17 Peter Rosin p...@lysator.liu.se tests: actually detect missing 'test' in 'if $foo = ...'. diff --git a/README.alpha b/README.alpha index a58167e..8c72c03 100644 --- a/README.alpha +++ b/README.alpha @@ -148,6 +148,62 @@ send the file `tests/testsuite.log' to the bug report mailing list, or optionally with: - Autoconf 2.59 or later - Automake 1.9.6 or later + +5. Version Numbering + + +People have complained that they find the version numbering scheme under +which libtool is released confusing... so we've changed it! + +It works like this: + + major-number.minor-number + +Releases with a major-number less than 1 were not yet feature +complete. Releases with a major-number of 1 used the old numbering +scheme that everyone disliked so much. Releases with a major-number +of 2 us the new scheme described here. If libtool ever undergoes a +major rewrite or substantial restructuring, the major-number will be +incremented again. + +If we make a patch release to fix bugs in a stable release, we use a +third number, so: + + major-number.minor-number.micro-number + +Version numbers are chosen to make it easy for users to decide two +things: + + Q: How `developed' is this release? + A: The higher the number, the better! + Q: How `stable' is this release? + A: - If the minor-number is even, it is a stable release, `2.0'. + - If the minor-number is odd, it is a development version with + new features compared to the last stable release, `2.1a'. + - If it has an `odd'[1] letter after the version number, it is a + snapshot direct from CVS, `2.1a'. + - If it has an `even'[1] letter after the version number, it is an + alpha quality release, `2.1b'. + - If it has three numbers in the version, it is a patch release, + fixing bugs from the stable release (with no new features), `2.0.1'. + +[1] We always increment the letter in the repository before *and* after +making a release tarball. This means that odd letters +(a,c,e,g...) only exist in the repository, and even letters are +used instantaneously for an alpha release. Since the odd lettered +version numbers cover many states of the tree, we also qualify them +by adding the cvs version of the ChangeLog: + +$ libtool --version +ltmain.sh (GNU libtool 1.1603 2004/09/12 22:02:07) 2.1a + +Copyright (C) 2004 Free Software Foundation, Inc. +This is free software; see the source for copying conditions. There is NO +warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. + +For more details about version numbers, see: + +http://www.gnu.org/software/libtool/contribute.html -- Copyright (C) 2004, 2005, 2006, 2007, 2008, 2009, 2010 Free Software Foundation, Inc. -- 1.7.2.2
Re: Version numbering
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. 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. 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 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'. 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). 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. -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Version numbering
-BEGIN PGP SIGNED MESSAGE- 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: http://www.panix.com/~zackw/exbib/2002/June/20 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. 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). 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. Besides the Linux kernel, what *else* uses that odd/even numbering scheme? I have seen a couple, but I can't remember any now. bernd -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE/eT9Q/FmLrNfLpjMRAum4AJ9GHw5I8nGlJ246o7V7r4D4dGOi4wCgrEij dcOWM80xrlJrVeBXMx8Umls= =fqIe -END PGP SIGNATURE- ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
RE: Version numbering
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Bernd Jendrissek -BEGIN PGP SIGNED MESSAGE- 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: http://www.panix.com/~zackw/exbib/2002/June/20 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 lexically. 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 MM.mm.pp; again if I'm packaging 255 patches to a release I think it deserves to have a new release number. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Version numbering
Alexandre Duret-Lutz wrote: Gary == Gary V Vaughan [EMAIL PROTECTED] writes: [...] Gary And that's why people find our version scheme confusing. I'm not sure Gary how we ended up working in this way, I think we copied it from Gary Automake? Tsk tsk tsk. Libtool used that scheme first. Automake copied it when we started to have branches. Ah, okay. I'm beginning to have a sneaking suspicion I might have invented it :-/ Silly me! Gary Anyhow, I'm fed up of having to explain it, when we could Gary just make it intuitive :-) 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: ] touch libtool-1.5.tar.gz libtool-1.6a.tar.gz libtool-1.6.tar.gz ] \ls -1 -v libtool-1.5.tar.gz libtool-1.6.tar.gz libtool-1.6a.tar.gz ] mv libtool-1.6a.tar.gz libtool-1.6-a.tar.gz ] \ls -1 -v libtool-1.5.tar.gz libtool-1.6-a.tar.gz libtool-1.6.tar.gz Cheers, Gary. -- ())_. Gary V. Vaughangary@(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
Re: Version numbering
Gary V. Vaughan wrote: Your point about `ls -v' is a good one though. I'll put an extra `-' before the letter: ] touch libtool-1.5.tar.gz libtool-1.6a.tar.gz libtool-1.6.tar.gz ] \ls -1 -v libtool-1.5.tar.gz libtool-1.6.tar.gz libtool-1.6a.tar.gz ] mv libtool-1.6a.tar.gz libtool-1.6-a.tar.gz ] \ls -1 -v libtool-1.5.tar.gz libtool-1.6-a.tar.gz libtool-1.6.tar.gz Except that ls -v is broken :-( ] touch libtool-1.5.tar.gz libtool-1.5.1.tar.gz ] \ls -1 -v libtool-1.5.1.tar.gz libtool-1.5.tar.gz Bzzzt. Wrong. I'll give this some more thought. Cheers, Gary. -- ())_. Gary V. Vaughangary@(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
Re: Version numbering
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. 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 [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Version numbering
Alexandre Duret-Lutz wrote: 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-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
Re: Version numbering
Scott James Remnant wrote: 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. It's only a concern to the RPM users and maintainers. If it's a CVS snapshot for the next version increment just timestamp the file. So file foo-1.0.tar.gz is a last release, file foo-1.1.tar.gz is to be the next release, then foo-1.1-.MM.DD.tar.gz is a snapshot release. Candidate releases can be named foo-1.1-RC1.tar.gz, incrementing the RC number for subsequent candidate files, if necessary. This scheme makes it easy to understand and explain. Earnie. -- http://www.mingw.org ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
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. Vaughangary@(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
Re: Version numbering
On Tue, 2003-09-30 at 17:58, Gary V. Vaughan wrote: After the next cron web update, please read: http://www.gnu.org/software/libtool/contribute.html and give me your feedback... Makes sense to me, seems to cover everything well enough to avoid any confusion about what kind of release things are or not. Also happens that dpkg agrees with your order (whereas it thinks 1.7 is older than 1.7a). I'm assuming that x.odd number means it's an alpha and x.even number means a stable release? 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 [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Version numbering
I am considering changing the version numbering scheme we use for alpha releases of libtool, which are currently a source of much confusion. The release rules in Makefile.am, and the release procedure documented in README-alpha are all that will need updating. I think when we branch for a release (say the upcoming 1.6), version numbers in the branch should continue to be 1.6.microalpha?, but that the trunk should bump its minor number to make it clear the trunk is very different to the stable branch: 1.7alpha?. We would of course continue to use odd letters for CVS revisions, and even letters for alpha releases. I am writing up how it works for the contributing to libtool webpage, and realised it's a bit hatstand at the moment. :-b Thoughts? -- ())_. Gary V. Vaughangary@(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
Re: Version numbering
On Mon, 29 Sep 2003, 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.microalpha?, but that the trunk should bump its minor number to make it clear the trunk is very different to the stable branch: 1.7alpha?. We would of course continue to use odd letters for CVS revisions, and even letters for alpha releases. Bumping the number to the next planned release level seems like the usual practice to me. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
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.microalpha?, but that the trunk should bump its minor number to make it clear the trunk is very different to the stable branch: 1.7alpha?. We would of course continue to use odd letters for CVS revisions, and even letters for alpha releases. Thoughts? Excellent! Peter ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Version numbering
On Monday, September 29, 2003, at 04:51 pm, Bob Friesenhahn wrote: On Mon, 29 Sep 2003, 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.microalpha?, but that the trunk should bump its minor number to make it clear the trunk is very different to the stable branch: 1.7alpha?. We would of course continue to use odd letters for CVS revisions, and even letters for alpha releases. Bumping the number to the next planned release level seems like the usual practice to me. And that's why people find our version scheme confusing. I'm not sure how we ended up working in this way, I think we copied it from Automake? Anyhow, I'm fed up of having to explain it, when we could just make it intuitive :-) Okay, I'll write it up to follow the new scheme, and then bump the version on HEAD to 1.6a. Cheers, Gary. -- ())_. Gary V. Vaughan gary@(oranda.demon.co.uk|gnu.org) ( '/ Research Scientist http://www.oranda.demon.co.uk ,_()) / )= GNU Hacker http://www.gnu.org/software/libtool \' ` `(_~)_ Tech' Authorhttp://sources.redhat.com/autobook =`---d__/ ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Version numbering
Gary == Gary V Vaughan [EMAIL PROTECTED] writes: [...] Gary And that's why people find our version scheme confusing. I'm not sure Gary how we ended up working in this way, I think we copied it from Gary Automake? Tsk tsk tsk. Libtool used that scheme first. Automake copied it when we started to have branches. Gary Anyhow, I'm fed up of having to explain it, when we could Gary just make it intuitive :-) 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'. -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Version numbering
On 2003-09-29T22:50+0200, Alexandre Duret-Lutz wrote: ) planning to make 2.2 2.3a 2.3. That would be counter ) intuitive. IMHO any numbering scheme ought to work with `ls -v'. ls ls -v ls -rt naim-0.11.5.1.tar.gz naim-0.11.5.1.tar.gz naim-0.11.5.tar.gz naim-0.11.5.7.tar.gz naim-0.11.5.7.tar.gz naim-0.11.5.1.tar.gz naim-0.11.5.8.1.tar.gz naim-0.11.5.8.1.tar.gz naim-0.11.5.7.tar.gz naim-0.11.5.8.tar.gz naim-0.11.5.8.tar.gz naim-0.11.5.8.tar.gz naim-0.11.5.9.cyg1.tar.gz naim-0.11.5.9.cyg1.tar.gz naim-0.11.5.8.1.tar.gz naim-0.11.5.9.cyg10.tar.gz naim-0.11.5.9.cyg9.tar.gz naim-0.11.5.9.tar.gz naim-0.11.5.9.cyg11.tar.gz naim-0.11.5.9.cyg10.tar.gz naim-0.11.5.9.cyg1.tar.gz naim-0.11.5.9.cyg9.tar.gz naim-0.11.5.9.cyg11.tar.gz naim-0.11.5.9.cyg9.tar.gz naim-0.11.5.9.tar.gz naim-0.11.5.9.tar.gz naim-0.11.5.9.cyg10.tar.gz naim-0.11.5.tar.gz naim-0.11.5.tar.gz naim-0.11.5.9.cyg11.tar.gz Several GNU projects (including GCC) do leave off .0's for anything past the minor number, so it seems ls -v can't be the final authority :/ What I do is timestamp pre-release snapshots, which does work with ls -v (and just ls). That is, I might have: naim-0.11.5-2002-12-08-1324.tar.gz naim-0.11.5.1-2002-12-18-0014.tar.gz naim-0.11.5.1-2002-12-21-1710.tar.gz naim-0.11.5.1.tar.gz naim-0.11.5.2-2002-12-23-0720.tar.gz ... naim-0.11.5.8-2003-06-03-1123.tar.gz naim-0.11.5.8.tar.gz naim-0.11.5.tar.gz 0.11.5.8-2003-06-03-1123 is the last pre-release before 0.11.5.8, and shows up before 0.11.5.8 in ls. The only problem is the lack of .0's that leave 0.11.5's pre-releases in the right spot, but sticks the 0.11.5 release after all of its subordinate releases. -- Daniel Reed [EMAIL PROTECTED] http://naim-users.org/nmlorg/ http://naim.n.ml.org/ There are people who do things and people who take the credit, and the trick is to be in the first group; there is a lot less competition. -- Dwight Morrow, American Diplomat http://site.n.ml.org/download/20030923195458/naim/naim-0.11.6.1.tar.bz2 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Version numbering
Daniel Reed [EMAIL PROTECTED] wrote: Several GNU projects (including GCC) do leave off .0's for anything past the minor number, so it seems ls -v can't be the final authority :/ It does not follow that this numbering scheme is a good one. I would argue that it isn't. The gcc maintainers seemed to be willing to add .0, but the request didn't come in time for 3.3. paul ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Version numbering change on IRIX
Robert, IMHO it isn't worth the bother to allow both, I'll just revert patch. Everyone agree? certainly :-) If the difference in shlib version numbering between Solaris/Linux and IRIX is really a FAQ that causes user confusion, perhaps this should be documented? Rainer ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Version numbering change on IRIX
On Fri, Nov 15, 2002 at 05:34:33PM +0100, Rainer Orth wrote: Robert, This change was a long time coming, so many people have complained about having libx.so.1 under Solars/Linux and having libx.so.2 under IRIX. Adding 1 to the version isn't necessary, I've looked everywhere I could think of to find out why this was done in the first place, but found none. I realize this change doesn't fix anything, and could potentially cause problems, but these will be transient, and it is consistent with other platforms. indeed: breaking every application linked against the old (overwritten) version of affected libraries is certainly a problem. This will be transient since people will be forced to rebuild/relink every affected application; something I consider a nightmare in big installations, especially when libraries used all over the place (like the GCC runtime libraries) are affected. I can already hear the outcry from affected users and admins; I don't want to be in the position to explain to them that their applications had to be broken for cosmetic reasons and consistency with other platforms. I think Rainer has a point. This change shouldn't be made lightly. Perhaps the add 1 for IRIX behaviour could be made a libtool option that is ON by default? -S ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
