[Top][All Lists]

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

Re: Autoconf version number after 2.70

From: Eli Schwartz
Subject: Re: Autoconf version number after 2.70
Date: Wed, 6 Jan 2021 15:55:39 -0500

On 1/5/21 9:31 AM, Zack Weinberg wrote:
On Mon, Jan 4, 2021 at 5:52 PM Paul Eggert <> wrote:
On 1/4/21 1:45 PM, Zack Weinberg wrote:

it sounds like your concern is not so much with a three-part
_numbering scheme_, but with the possiblity that we might put out
2.70.n _after_ 2.71.  What if we say that, at least for the time being
(until some hypothetical future where the project has a lot more
resources) we won’t do that?

In that case the two numbering schemes are functionally equivalent, and
it becomes almost entirely a marketing issue.


I tested that script, and it correctly handles three-part version
numbers reported by autoconf.  It will need to be changed if Emacs
decides to _require_ a three-part autoconf version

... and at that point the proposed numbering scheme will be more hassle
for Emacs developers than if Autoconf had stuck with the current scheme,
because they'll have to alter the code in instead of merely
changing AC_PREREQ(2.65) to AC_PREREQ(2.73) in

After thinking about it a bit more, this technical argument against
three-part versions is quite compelling ... but I still find the
marketing argument *for* three-part versions to be quite compelling.
I would like to hear some more people's opinions; cc:ing Eric and

If you'll allow me to butt in...

I don't find this technical argument compelling; emacs doesn't need to require a specific patch release.

From a technical point of view, my understanding here is that autoconf will continue its current policy of trying not to break things, but occasionally, when it's not practical to directly release from master, a handful of "very important" bugfixes need/should be released on their own. This much is set in stone; the question is what to name it. Semantically, it feels more proper to use subrevisions of the point where you branched off.

More generally, it seems like you're not all thrilled by the use of versions like "2.69" because there's no difference, in your minds, whether the next version is 2.71 or 3.0, they'd need the same feature release stability concerns. Maybe a better version scheme would be like systemd -- a single monotonically increasing integer, which adds new features and tries not to break anything and remain compatible with previous versions.

You could bump to autoconf 3.0, and the next version would be 4.0, then 5.0, and you'd save the second component for patch releases.

Either way, I'm entirely sure using semantically recognizable versioning for hotfix releases -- whether it be 2.70.1 or 3.1 will aid e.g. linux distros seeking to package new autoconf versions in quickly making the decision "do I package this now or do I wait until after the Debian freeze" -- and a hotfix release, being by nature nothing but a collection of urgent backports on top of a *maintenance branch*, is something you definitely want everyone to package and use ASAP with expedited testing. There should never be a reason *not* to upgrade from "version" to "version+hotfix".


Name your hotfixes something recognizably different from your feature releases.

Eli Schwartz
Arch Linux Bug Wrangler and Trusted User

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

reply via email to

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