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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 68274 in the body.
You can then email your comments to 68274 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Carl Hansen <carlhansen <at> gnu.org>
To: bug-automake <at> gnu.org
Subject: automake 1.16j nonnumerical version confuses scripts
Date: Fri, 5 Jan 2024 23:03:44 -0500

Building a package (happens to be "jami") , which runs a script it its 
build process that checks for automake

      expr: non-integer argument    
      automake (GNU automake) 1.16j    
    
      Fatal error: automake 1.7 or higher is required.  Please set $AUTOMAKE    
      to point to a newer automake, or upgrade.    

Problem is the script expects numerical version, thus gets confused.

Next version, make it something like  "automake 1.16.99999" or something.

Message #8 received at 68274 <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: carlhansen <at> gnu.org
Cc: 68274 <at> debbugs.gnu.org
Subject: Re: bug#68274: automake 1.16j nonnumerical version confuses scripts
Date: Sat, 6 Jan 2024 15:37:05 -0700

Carl - sorry, you'll need to adjust your script.  Automake and other
packages have used letters for pretests for decades, and it's not
plausible to change now.

Also, I have the impression that other packages use random git hexids in
their pretest releases, which aren't numeric either. -k

Message #11 received at 68274 <at> debbugs.gnu.org (full text, mbox):

From: Mike Frysinger <vapier <at> gentoo.org>
To: Karl Berry <karl <at> freefriends.org>
Cc: carlhansen <at> gnu.org, 68274 <at> debbugs.gnu.org
Subject: Re: bug#68274: automake 1.16j nonnumerical version confuses scripts
Date: Fri, 12 Jan 2024 23:19:44 -0500

[Message part 1 (text/plain, inline)]

On 06 Jan 2024 15:37, Karl Berry wrote:
> Automake and other packages have used letters for pretests for decades,

true ...

> and it's not plausible to change now.

eh ?  there is nothing requiring or restricting the current version behavior
other than "it's always been this way".  but that doesn't mean it's better.

there's no reason we couldn't use more modern convention here like -rc#.
appending a letter at the end to indicate a *pre*release is extremely
uncommon nowadays.

> Also, I have the impression that other packages use random git hexids in
> their pretest releases, which aren't numeric either. -k

some do, but they use separators which makes it easier to split+compare.
if they smashed it together, it'd be impossible to determine where the
version stopped and where the git sha started.

e.g. 1.2.3-gab989de
-mike

[signature.asc (application/pgp-signature, inline)]

Message #14 received at 68274 <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: vapier <at> gentoo.org
Cc: carlhansen <at> gnu.org, 68274 <at> debbugs.gnu.org
Subject: Re: bug#68274: automake 1.16j nonnumerical version confuses scripts
Date: Sat, 13 Jan 2024 15:58:26 -0700

    there is nothing requiring or restricting the current version behavior
    other than "it's always been this way".  

True.

    but that doesn't mean it's better.

No way to know what release or test scripts might be relying on the
current convention. Changing for the sake of change doesn't seem good.

    there's no reason we couldn't use more modern convention here like -rc#.

I don't much like it, since "rc" always makes me think first of rc
files. It also wouldn't fix the problem in jami (still not numeric).

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.

Message #17 received at 68274 <at> debbugs.gnu.org (full text, mbox):

From: Mike Frysinger <vapier <at> gentoo.org>
To: Karl Berry <karl <at> freefriends.org>
Cc: carlhansen <at> gnu.org, 68274 <at> debbugs.gnu.org
Subject: Re: bug#68274: automake 1.16j nonnumerical version confuses scripts
Date: Sun, 14 Jan 2024 01:49:46 -0500

[Message part 1 (text/plain, inline)]

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.

i cut more inline responses to avoid further bikeshedding on the topic.
we can agree to disagree.
-mike

[signature.asc (application/pgp-signature, inline)]

Message #20 received at 68274 <at> debbugs.gnu.org (full text, mbox):

From: "Zack Weinberg" <zack <at> owlfolio.org>
To: "Mike Frysinger" <vapier <at> gentoo.org>, "Karl Berry" <karl <at> freefriends.org>
Cc: carlhansen <at> gnu.org, 68274 <at> debbugs.gnu.org, autoconf <at> gnu.org
Subject: Re: bug#68274: automake 1.16j nonnumerical version confuses scripts
Date: Tue, 16 Jan 2024 21:48:48 -0500

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.

zw

Message #23 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Sam James <sam <at> gentoo.org>
To: Zack Weinberg <zack <at> owlfolio.org>
Cc: Mike Frysinger <vapier <at> gentoo.org>, autoconf <at> gnu.org,
 Karl Berry <karl <at> freefriends.org>, bug-automake <at> gnu.org, carlhansen <at> gnu.org,
 68274 <at> debbugs.gnu.org
Subject: Re: 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

Message #29 received at 68274 <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: carlhansen <at> gnu.org, sam <at> gentoo.org
Cc: 68274 <at> debbugs.gnu.org
Subject: Re: bug#68274: automake 1.16j nonnumerical version confuses scripts
Date: Sun, 21 Jan 2024 14:42:12 -0700

I changed the pretest version to 1.16.90. Closing.

Message #37 received at 68274 <at> debbugs.gnu.org (full text, mbox):

From: Mike Frysinger <vapier <at> gentoo.org>
To: Karl Berry <karl <at> freefriends.org>
Cc: carlhansen <at> gnu.org, 68274 <at> debbugs.gnu.org, sam <at> gentoo.org
Subject: Re: bug#68274: automake 1.16j nonnumerical version confuses scripts
Date: Mon, 22 Jan 2024 16:49:13 -0500

[Message part 1 (text/plain, inline)]

On 21 Jan 2024 14:42, Karl Berry wrote:
> I changed the pretest version to 1.16.90. Closing.

thx bud.  i appreciates you.
-mike

[signature.asc (application/pgp-signature, inline)]

Previous Next

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