> 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.
> 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.
> 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.
-- With Valediction, Kamila Szewczyk (https://iczelia.net)
OpenPGP_0xC868F0B6DE38409D.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
