Re: Autoconf version number after 2.70

[John Calcote]

On Wed, Jan 6, 2021 at 1:56 PM Eli Schwartz <eschwartz@archlinux.org> wrote:

> 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.
>
>
I'm confused as to why this is even an argument.

1. There is a well-established and well-understood standard for Linux
package versions.
2. There is a well-established and well-understood standard for Autoconf
package versions.

In the first case, it's the major.minor.revision system where major version
changes represent major feature releases with potentially non-backward
compatible changes, minor version changes represent minor feature
enhancements that are generally considered backward compatible, and
revision changes represent "hotpatch" fixes off the associated minor
version release.

The second case overrides the first - the way Autoconf has been doing it
for years - generally the same as  the first case, except that hotpatch
fixes have been rolled into minor version changes.

Changing to an entirely different system will just confuse everyone.
Sticking with the current (defacto) standard for Autoconf will not confuse
anyone. If there's a compelling reason to change, I'd vote for just
collapsing to case 1, which is the generally accepted standard for all
packages.

My two cents, since it was requested.

John