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