[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.