Re: Autoconf version number after 2.70

[Zack Weinberg]

On Tue, Jan 5, 2021 at 9:31 AM Zack Weinberg <zackw@panix.com> wrote:
> 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.

After a bunch more thought, I went with 2.71 for the patch release
(from the branch) that I just uploaded.

This is why I changed my mind: just going through my own mental
high-priority TODO list, I can think of several changes that would not
qualify as "bug fixes" but would still qualify for the branch:

- adding C2017 and C++2017 detection
- adding arguments to AC_PROG_CC to specify that C99 is preferred to
C2011 (as requested e.g. by the Postgres folks)
- adding arguments to AC_PROG_CC/CXX/... to specify that configure
should *not* error out if this compiler is unavailable (bug 110394)
- AC_PROG_FLEX (and AC_PROG_BISON) as discussed in bug 110266
- merging back the macros that use AC_TRY_RUN and whose
cross-compilation support has been improved in gnulib, *including*
--enable-cross-guesses
- shell variable expansion in AC_INIT arguments, for feature parity
with AM_INIT_AUTOMAKE

But at the same time I can think of a few changes I want to work on
soon that would *not* qualify for an expedited release from the
post-2.70 branch; they'd need a whole bunch more testing first.

- make -j -based parallel autotest
- the proposal to have _AC_DO evaluate $CC twice for consistency with Make
- revising the locking protocol for autom4te.cache

So I have come around to Paul's position, that the branch is useful
but trying to make a distinction between low-risk and high-risk
releases in the version number is not.

zw