On Thu, Dec 31, 2020 at 3:41 AM Paul Eggert <eggert@xxxxxxxxxxx> wrote: > > On 12/30/20 11:23 AM, Zack Weinberg wrote: > > > 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. > > My feeling is quite the opposite. Publishing two sets of releases is by > and large useful only for projects like GCC that have enough development > resources where it makes sense to support both sets. But Autoconf > development doesn't have resources to properly support even one such > release series. It’s interesting that we basically agree on the facts of the situation (there is a need for bugfix-only releases post-2.70, and we don’t have the developer hours to put out those releases and work on a future feature release at the same time) but we come to exactly opposite conclusions. > And it's not just the overhead for Autoconf developers. Having two sets > of releases complicates life for Autoconf users. Should users support > both 2.70.1 and 2.71 if both releases are available and are "latest"? > What if 2.70.2 has a bugfix that's not in 2.73 - how do users employ > m4_version_compare then? Of course there are solutions to these > problems, but they add complexity and there's a cost to that. First off, my answer to “What if 2.70.2 has a bugfix that's not in 2.73” is “We never do that; every fix on the branch must also be present on to the trunk.” (It might not be the exact same _change_ on the branch, but it had better be the same test case.) Second, 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? That each 2.x release branch will be closed when 2.(x+1) comes out? Do you still have reservations? How many of those reservations would go away if 2.(x+1) from now on was consistently referred to as 2.(x+1).0 ? ... > > I think it’s extra important right now ... for it to be as obvious > > as possible that what we’re putting out *is* a bug-fix-only > > release. > > It'll already be *plenty* obvious. We'll put it in the NEWS etc. > Changing the release-numbering scheme won't make much difference to how > obvious it is, and won't be worth the aggravation. This is the part of your position that I really don’t agree with. I think going to three-part version numbers and calling the next release 2.70.1 makes it *much* more obvious that the next release is a bug-fix-only release, compared to just mentioning it in NEWS. With a three-part version number, you know what you’re getting before you even download the tarball. I don’t see this as overengineering at all, either. Three-part version numbers are common and well-understood. In fact, as David Wheeler points out, in some ways they are _better_ understood than two-component version numbers. > > 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, > > That was a concern, yes. You're right that m4_version_compare should be > good but I was concerned that there may be ad-hoc shell scripts etc. out > there. For example, I doubt whether Emacs's Autoconf version-number > checker <https://git.savannah.gnu.org/cgit/emacs.git/tree/autogen.sh> > deals with three-part version numbers correctly. 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 (suppose 2.70 doesn’t work for them but 2.70.2 does) but they’ll know they need to fix the script if they do that. I’d expect most such scripts to be in the same boat. [from reply to David Wheeler] > Many programs use SemVer, but many don't. Emacs doesn't. Coreutils > doesn't. Grep doesn't. Mailutils doesn't. GNU parallel doesn't. Ubuntu > doesn't. Chromium doesn't. iOS doesn't. There are lots of other examples. > > Even GCC doesn't really use SemVer. Sure, GCC's version numbers have > three parts but they've essentially given up on SemVer-style releases > since GCC 5.1 came out in 2015. > > More to the point, Autoconf's sister project Automake uses SemVer and > it's not worked well. For example, features regularly get added in patch > versions even though SemVer says not to do that. “Lots of other projects don’t do SemVer and/or do it wrong” does not strike me as a reason to give up on the idea altogether. (The biggest problem with SemVer in practice, IMNSHO, is that marketing people like bumping the major number, even though a low major number is a _badge of honor_ in SemVer world.) > SemVer has its place (e.g., OO libraries where every little detail > matters) Based on my experience with the run-up to 2.70 I am inclined to say that every little detail _does_ matter with autoconf. :-) > > It’s often unclear if “2.70” is before “2.8”. When there are 3 > > numbers, the version number Is unambiguously *not* a real number & > > the confusion mostly disappears. > > That hasn't been a problem since Autoconf 2.10 came out in 1996, and at > the rate we're going it won't be a problem again until and unless > Autoconf 2.100 comes out in (say) 2049. I just saw someone call 2.70 “2.7” in a bug report, so I’d say it is a problem right now. zw
