Jonathan Wakely <[email protected]> writes: > On Tue, 20 Jan 2026 at 09:20, Jonathan Wakely <[email protected]> wrote: >> >> On Mon, 19 Jan 2026 at 19:16, Zack Weinberg <[email protected]> wrote: >> > >> > On Thu, Jan 15, 2026, at 6:03 PM, Paul Eggert wrote: >> > > On 1/14/26 04:07, Jonathan Wakely wrote: >> > >> Would it make sense to do an Autoconf 2.72.1 release which is >> > >> identical to 2.72 except it fixes this serious incompatibility with >> > >> GCC 16? >> > > >> > > Easier would be to simply release what we've got. >> > >> > I was thinking the same thing. We have a whole bunch of relatively low- >> > risk patches stacked up in git, might as well call them 2.73. >> > >> > I'd like to see some broad testing first, though. What if I put out an >> > alpha release sometime this week and distribution maintainers do some >> > mass rebuilds with it? Also, does anyone know of any high-importance >> > patches waiting for review, or other high-importance bugs that should be >> > addressed ASAP? >> >> A 2.73 release seems fine, but a 2.72.1 would be zero risk and has >> already been tested. That would be easier for distros to switch to in >> stable releases. If there isn't an official 2.72.1 then distros are >> just going to patch 2.72 locally (we've already done this in Fedora, >> as have Gentoo) and now we have at least three slightly different >> versions of 2.72 in circulation, generating slightly different >> 'configure' files, but claiming to be > > (sorry, hit send too soon!) > > ... claiming to be 2.72
Yes, the unfortunate thing is that 2.73 will never be backported in a distro and upstreams often cling to old autoconf (partly for AC_PREREQ reasons). But I understand Paul's point about the minimum cost for a release too.
signature.asc
Description: PGP signature
