On Wed, Jan 6, 2021 at 1:56 PM Eli Schwartz <eschwartz@xxxxxxxxxxxxx> wrote: > On 1/5/21 9:31 AM, Zack Weinberg wrote: > > On Mon, Jan 4, 2021 at 5:52 PM Paul Eggert <eggert@xxxxxxxxxxx> 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
