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.
From a technical point of view, my understanding here is that autoconf will continue its current policy of trying not to break things, but occasionally, when it's not practical to directly release from master, a handful of "very important" bugfixes need/should be released on their own. This much is set in stone; the question is what to name it. Semantically, it feels more proper to use subrevisions of the point where you branched off.
More generally, it seems like you're not all thrilled by the use of versions like "2.69" because there's no difference, in your minds, whether the next version is 2.71 or 3.0, they'd need the same feature release stability concerns. Maybe a better version scheme would be like systemd -- a single monotonically increasing integer, which adds new features and tries not to break anything and remain compatible with previous versions.
You could bump to autoconf 3.0, and the next version would be 4.0, then 5.0, and you'd save the second component for patch releases.
Either way, I'm entirely sure using semantically recognizable versioning for hotfix releases -- whether it be 2.70.1 or 3.1 will aid e.g. linux distros seeking to package new autoconf versions in quickly making the decision "do I package this now or do I wait until after the Debian freeze" -- and a hotfix release, being by nature nothing but a collection of urgent backports on top of a *maintenance branch*, is something you definitely want everyone to package and use ASAP with expedited testing. There should never be a reason *not* to upgrade from "version" to "version+hotfix".
tl;drName your hotfixes something recognizably different from your feature releases.
-- Eli Schwartz Arch Linux Bug Wrangler and Trusted User
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
