> There are other packages that use date stamps instead of version > numbers, so either those parsers can handle that or they already fail > on some existing packages. That is their problem, not ours.
They won't fail on such packages. They won't be used to begin with, and instead, the maintainers will have to update them manually. I don't see the benefits of making everything more annoying for everyone and insisting on the timestamp instead of a simple incrementing version number.
> GNU config is mature and *every* published version is expected to be > stable, correct, and deployable. There are no "development" versions > of these scripts in the main repository (anymore?).Well, if you insist... I ran a script to search the repository in parallel for shell syntax errors and I quickly got this result:
9bbefc1 -- "config.guess (:Darwin::*): Simplify UNAME_PROCESSOR." was committed on 28 May 2019, replacing an `if' with a `case' but left the closing `fi'. As a result trying to run `sh -n config.guess' unconditionally fails. A fix has been committed 2h30min later, but if someone depended on the trunk version being "stable, correct, and deployable," they were out of luck on that day. I disagree that the script has no development versions; every version is a development version that is incidentally seldom usable as a release version.
> That (drop in new config.{guess,sub}) works reliably *because* there
> will never be a SemVer major release 2 of GNU config. All future
> version retain compatibility with the old interface, which means that
> even an ancient configure can use the latest scripts.
Simple grep for common breaking change keywords over all commit messages
yields the following result:
28ea239 -- "config.sub: Remove windows-gnu." was committed on 19 September 2023. A breaking change is defined as a previously accepted input becoming an error. Running `sh config.sub x86_64-windows-gnu' demonstrates exactly this behaviour before and after the commit was pushed.
(Incidentally, I recall having to deal with this particular breakage in CI before...)
-- With Valediction, Kamila Szewczyk (https://iczelia.net) On 10/25/26 3:05 AM, Jacob Bachmeyer wrote:
On 10/24/26 06:47, Kamila Szewczyk wrote:> By that logic there should never be a major release "2": the > config.guess and config.sub scripts are meant to be "drop in" updates > for existing packages to add support for new platforms.So be it. Sadly, you have failed to consider that a (SemVer or general) version number consisting of one component, such as "v1" or "1" would require special casing for many parsers (e.g. the Rust `version-number' crate, Go `dbm' version validation, dotNET `System.Version.Parse'), as they support version numbers containing two or more components. This would have been fine, but then version bumps have to be done manually and it's a source of unnecessary annoyance to distribution maintainers.A solution has already been proposed: a date stamp (which the scripts already each carry) for each snapshot instead of a version number. I wrote a simple pipeline to pick the later timestamp out of the files and sent it to the list.There are other packages that use date stamps instead of version numbers, so either those parsers can handle that or they already fail on some existing packages. That is their problem, not ours.> That is an impressive success for Autoconf: a package successfully > ported to a new CPU architecture with no code changes.I have done this many times, but I (somewhat) fail to see the relevance of it to this particular discussion.That (drop in new config.{guess,sub}) works reliably *because* there will never be a SemVer major release 2 of GNU config. All future version retain compatibility with the old interface, which means that even an ancient configure can use the latest scripts.> There is a separate issue, though: downstream packagers need a stable, > identifiable source archive.I am currently having this problem with automake. We depend on a handful of things from TeXinfo, gnulib and config. However, Savannah/ cgit is down more often than it is not, so our fetch script does not work, and I botched the Automake 1.19 release because I ran `make fetch' in an inopportune moment and bundled a broken version of GNU TeXinfo. Having a release cycle, even for things as mundane as config, is important because it gives a distinction between lousy development versions and something that is (by some stretch) considered to be stable, correct and deployable.GNU config is mature and *every* published version is expected to be stable, correct, and deployable. There are no "development" versions of these scripts in the main repository (anymore?).-- Jacob
OpenPGP_0xC868F0B6DE38409D.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
