On Sun, Jan 14, 2024, at 1:49 AM, Mike Frysinger wrote: > On 13 Jan 2024 15:58, Karl Berry wrote: >> Another alternative: when this came up 30-odd years ago, rms changed the >> GNU maintainers doc to suggest x.y.90, .91, etc. for pretests. Doing >> that would at least have the benefit of following a recommendation, and >> as a side effect, would also fix jami's assumption (poor practice though >> it is, IMHO). >> https://gnu.org/prep/maintain/html_node/Test-Releases.html#Test-Releases >> >> Doing an ls -R on alpha (fp:/srv/data/ftp-mirror/alpha/gnu), it seems >> (rough guess with some grep counting) the .90 convention is by far the >> most common approach (a couple thousand), followed by the suffix letter >> a la automake (~750 releases), followed by -rc (~360). -hexid and -date >> are both trailing the field. Other random conventions also present. >> >> It all feels like bikeshedding to me, so my inclination is to do >> nothing. If we do change, I think we should use .90. --best, karl. > > using .90 is certainly better than single-letters. if you're fine with > it, then let's switch. For what it's worth, I had planned to switch Autoconf, starting with the next release, to use *some* version numbering scheme for beta releases that sorts correctly according to things like strverscmp() and dpkg --compare-versions. The "append a letter to the version number intended for the final release" convention makes these algorithms sort the betas *after* the release, which is backwards. My plan *was* to append letters to the version number for the *previous* release, with a gap (e.g. 2.72{j,k,...} would be prereleases for 2.73), which I think is what Automake is doing now) but I like .9x version numbers better because it's more common (as you observed) and therefore more likely to be understood at sight. I'd actually forgotten that .9x versions were an official GNU recommendation. zw
