Re: Autoconf version number after 2.70

[Eli Schwartz]

On 1/5/21 9:31 AM, Zack Weinberg wrote:
> On Mon, Jan 4, 2021 at 5:52 PM Paul Eggert <eggert@cs.ucla.edu> 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.
>
> Yes.
>
> > > 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 autogen.sh instead of merely
> > changing AC_PREREQ(2.65) to AC_PREREQ(2.73) in configure.ac.
>
> 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
> Karl.

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

tl;dr

Name your hotfixes something recognizably different from your feature 
releases.

--
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User

OpenPGP_signature
Description: OpenPGP digital signature