Re: Autoconf version number after 2.70

[Zack Weinberg]

On Wed, Dec 23, 2020 at 7:59 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
>
> Given the changes being discussed (which seem good ones), I suggest
> calling the next Autoconf release 2.71 not 2.70.1, as the latter
> would use a new-to-Autoconf numbering convention that might be more
> trouble than it's worth.
>
> There was little difference (and only a month) between Autoconf 2.66
> and 2.67, so there's precedent for putting only a few changes into
> Autoconf 2.71 and publishing it relatively quickly.

I’ve thought about this suggestion for several days now.

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, such as programs that assume Autoconf’s version numbers
always have only two components?  If so, can you articulate how much
of a risk you think we’d be taking by using a three-component version
number, and why?  I note that m4_version_compare and everything built
on top of it (e.g. AC_PREREQ) appear to be capable of handling version
numbers with arbitrarily many components.

Leaving that aside for now, I think Autoconf (the project) is in a
different place now than it was at the time of 2.66, and this means
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.

(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, such as changing how quotation within CFLAGS is
handled, changing the rules for when a configure script enters
cross-compilation mode, adding gnulib’s
--enable-cross-guesses={conservative|risky}, etc.)

(It’s hard to say how long “an extended period” will be, it depends on
the rate at which people update *and* the time until the next feature
release, but I’m guessing at least a year.)

I’m saying this mainly because of the limited people-power we have at
the moment—there isn’t even anyone who can promise to review
individual patches in a timely fashion, let alone manage the next
feature release.  If we maintain a bugfixes-only branch as well as the
development trunk, we compensate for the unpredictable amount of time
it may be until the next feature release.  Redistributors will be able
to grab the tip of that branch whenever there’s a fix they need,
without worrying about breaking anything.  (This is how Linux
distributions have used GCC release branches for many years.)

I’m also saying this because we’ve seen from the 2.70 release cycle
that patches going onto development trunk have often, in the past,
been inadequately tested and debugged, and/or had bigger compatibility
implications than anyone realized.  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.
What we can do *right now* is add a layer of process in between the
trunk and this hypothetical bugfixes-only branch.  Even if it’s just
in each individual committer’s head, a requirement to check all
patches into the trunk first, and then think about whether the patch
both fixes a bug and doesn’t risk anything else, before applying it to
the branch (via `git cherry-pick`), should go some way toward
*keeping* that branch safe to grab.

Now, there’s no technical reason why a release from the branch
couldn’t be called 2.71, but there are a couple of non-technical
reasons why it might be better to call it 2.70.1 (and then .2, .3, …).
The most important one is messaging.  Given that Autoconf hasn’t made
x.y.z releases in the past, our users will be looking to other
projects to understand what an x.y.z release *means*, and the common
understanding is that these are bug-fix-only releases.  I think it’s
extra important right now—only a month or so after the first stable
release in eight years, which shipped with 3300 words of release
notes—for it to be as obvious as possible that what we’re putting out
*is* a bug-fix-only release.  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.

Finally, I need to remind everyone that I’m no longer being paid to
work on Autoconf, and my volunteer hacking time will be quite limited
between now and June at the earliest.  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.

zw