autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: new snapshot available: autoconf-2.72c


From: Carlos O'Donell
Subject: Re: new snapshot available: autoconf-2.72c
Date: Mon, 27 Mar 2023 14:30:39 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0

On 3/27/23 13:45, Sam James wrote:
> 
> "Zack Weinberg" <zack@owlfolio.org> writes:
> 
>> On Mon, Mar 27, 2023, at 11:38 AM, Jim Meyering wrote:
>>> We're overdue for a new release, so here's a snapshot in
>>> preparation for that, which I want to call 2.73 (skipping 2.72).
>>> There has never been an autoconf-2.72 release, yet `git describe`
>>> now prints 2.72c and has been printing strings like
>>> v2.72a-92-g8db00aa8 for years.
>> 
>> Just as a note, I thought this version numbering scheme was weird
>> too the first time I encountered it, but the historical practice
>> has been that 2.72a, 2.72b, 2.72c, etc. are beta releases of 2.72.
> 
> FWIW, the historical practice doesn't work very well for at least 
> Gentoo's package manager, and I believe this is true for other 
> distributions too.

Agreed. You are correct.

It doesn't work for Fedora either, where we often want to use git describe.

For glibc I'm using `glibc-2.38.9000` tagging for pre-glibc-2.39 releases, and 
this
sorts correctly after glibc-2.38 but before glibc-2.39.

For detailed notes for glibc see:
https://sourceware.org/glibc/wiki/Release/#Second_Tag_.5BREQUIRED.5D_.28At_release.29

> That is, 2.72a > 2.72, although 2.72_alpha < 2.72. So Jim's decision 
> in this case has worked well here at least.
>> 
>>> https://meyering.net/ac/autoconf-ss.tar.xz      1.4 MB 
>>> https://meyering.net/ac/autoconf-ss.tar.xz.sig 
>>> https://meyering.net/ac/autoconf-2.72c.tar.xz
>> 
>> Are you able to upload this to ftp.gnu.org as an official beta?
>> 
> 
> or alpha.gnu.org, I suppose.

Agreed.

Guidance is to use alpha.gnu.org for non-final releases to avoid any confusion.


>>> NEWS =====================================
>> ...
>>> Port to compilers that moan about K&R func decls More fixes for
>>> compilers that reject K&R function definitions.
>> 
>> Compatibility with compilers that reject unprototyped function
>> declarations should maybe get a more prominent NEWS entry.
>> 
> 
> Yeah, given it's the impetus.
> 
>> zw
> 

-- 
Cheers,
Carlos.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]