GNU bug report logs - #68274
automake 1.16j nonnumerical version confuses scripts

Previous Next

Full log

View this message in rfc822 format

From: Sam James <sam <at> gentoo.org>
To: Zack Weinberg <zack <at> owlfolio.org>
Cc: vapier <at> gentoo.org, autoconf <at> gnu.org, karl <at> freefriends.org, 68274 <at> debbugs.gnu.org, carlhansen <at> gnu.org
Subject: bug#68274: automake 1.16j nonnumerical version confuses scripts
Date: Wed, 17 Jan 2024 03:24:58 +0000

"Zack Weinberg" <zack <at> owlfolio.org> writes:

> On Sun, Jan 14, 2024, at 1:49 AM, Mike Frysinger wrote:
>> On 13 Jan 2024 15:58, Karl Berry wrote:
>>> Another alternative: when this came up 30-odd years ago, rms changed the
>>> GNU maintainers doc to suggest x.y.90, .91, etc. for pretests. Doing
>>> that would at least have the benefit of following a recommendation, and
>>> as a side effect, would also fix jami's assumption (poor practice though
>>> it is, IMHO).
>>> https://gnu.org/prep/maintain/html_node/Test-Releases.html#Test-Releases
>>> 
>>> Doing an ls -R on alpha (fp:/srv/data/ftp-mirror/alpha/gnu), it seems
>>> (rough guess with some grep counting) the .90 convention is by far the
>>> most common approach (a couple thousand), followed by the suffix letter
>>> a la automake (~750 releases), followed by -rc (~360). -hexid and -date
>>> are both trailing the field. Other random conventions also present.
>>> 
>>> It all feels like bikeshedding to me, so my inclination is to do
>>> nothing.  If we do change, I think we should use .90.  --best, karl.
>>
>> using .90 is certainly better than single-letters.  if you're fine with
>> it, then let's switch.
>
> For what it's worth, I had planned to switch Autoconf, starting with the
> next release, to use *some* version numbering scheme for beta releases
> that sorts correctly according to things like strverscmp() and
> dpkg --compare-versions.  The "append a letter to the version number
> intended for the final release" convention makes these algorithms sort
> the betas *after* the release, which is backwards.
>
> My plan *was* to append letters to the version number for the *previous*
> release, with a gap (e.g. 2.72{j,k,...} would be prereleases for 2.73),
> which I think is what Automake is doing now) but I like .9x version numbers
> better because it's more common (as you observed) and therefore more likely
> to be understood at sight.  I'd actually forgotten that .9x versions were
> an official GNU recommendation.
>

I was planning on finally filing a bug for this because I couldn't really
package the latest automake pre-release given it totally breaks our
sorting (and afaik sorting in every other PM too).

We're used to .9x and it works fine for us.

thanks,
sam

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.