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
