Re: Autoconf version number after 2.70

[Paul Eggert]

On 12/30/20 11:23 AM, Zack Weinberg wrote:

> we need to make a more careful distinction between minor releases
> that might have compatibility issues, and point releases that were
> guaranteed only to fix bugs, than we used to.  Specifically, I think
> we need to maintain a release branch based on 2.70 for an extended
> period, and promise that that branch will only ever carry bugfixes on
> top of 2.70.

My feeling is quite the opposite. Publishing two sets of releases is by 
and large useful only for projects like GCC that have enough development 
resources where it makes sense to support both sets. But Autoconf 
development doesn't have resources to properly support even one such 
release series.

And it's not just the overhead for Autoconf developers. Having two sets 
of releases complicates life for Autoconf users. Should users support 
both 2.70.1 and 2.71 if both releases are available and are "latest"? 
What if 2.70.2 has a bugfix that's not in 2.73 - how do users employ 
m4_version_compare then? Of course there are solutions to these 
problems, but they add complexity and there's a cost to that.

I'm more of an Autoconf user than I am an Autoconf developer, and from 
the user point of view I'd rather keep things simple, and stick with 
2.71 when it comes out, and then to 2.72 when it comes out, etc.

> (This might seem like a weird thing to insist on right now, because
> *trunk* currently only has bugfixes on top of 2.70, but there are
> already several patches pending review that would not be appropriate
> for the branch,

That's fine. Autoconf can have multiple branches on Git to explore 
alternate futures. I just would rather not have the multiplicity bleed 
through downstream.

> There are a whole bunch of ways we
> could reduce the chances of this in the future—more thorough patch
> review, beefing up the test suite, CI that runs our test suite on more
> different platforms, CI that rebuilds *other packages* using trunk
> autoconf—but all of them are going to take time to put in place.

Absolutely, and all those things would be good to have. Unfortunately 
all this will take more work if we complicate the release story that we 
tell users. If we want CI the simplest way to do it is to stick to a 
simple release history, like Autoconf has always done.

> The most important one is messaging.

Yes, that's my biggest worry as well.

> I think it’s
> extra important right now ... for it to be as obvious as possible that what 
> we’re putting out
> *is* a bug-fix-only release.

It'll already be *plenty* obvious. We'll put it in the NEWS etc. 
Changing the release-numbering scheme won't make much difference to how 
obvious it is, and won't be worth the aggravation.

> A less important, but still significant,
> factor is that if we put out 2.71 from the branch, and then 2.72 from
> trunk, and then we discover that we need to do another release from
> the older branch, we’d *have* to start using three-component versions
> at that point, which would be more confusing than starting now.

That's not gonna happen, because we don't have the resources.

Even if it happened, it wouldn't be more confusing to users to do it 
then, than to do it now.

> Maintaining a bug-fixes-only
> branch based on 2.70, and doing releases from it as necessary, is
> something I can do as a volunteer.  Managing the next *feature*
> release, on the other hand, will not fit into my copious free time.

That was my thought as well. And I don't see anybody doing the next 
feature release any time soon. When that happens, we can worry about 
release numbering. In the meantime let's just stick with the 
longstanding release-numbering scheme, and not over-engineer the 
release-numbering in a development design that we may wish we had but 
don't have the resources for.

> Are you saying that a version number like “2.70.1”, with three
> components, might be “more trouble than it’s worth” for *technical*
> reasons,

That was a concern, yes. You're right that m4_version_compare should be 
good but I was concerned that there may be ad-hoc shell scripts etc. out 
there. For example, I doubt whether Emacs's Autoconf version-number 
checker <https://git.savannah.gnu.org/cgit/emacs.git/tree/autogen.sh> 
deals with three-part version numbers correctly.