On 10/25/26 06:17, Kamila Szewczyk wrote:
> 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.
Simple: the GNU config scripts already have timestamps, and outside
standards (like refusing to accept YYYYMMDD as a version number) are not
our problem.
(<URL:https://www.gnu.org/prep/standards/standards.html#Non_002dGNU-Standards>)
> 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.
I did say "(anymore?)" and your counter-example is from seven years ago
and was fixed in less than three hours.
I believe that you have mentioned a recent bungled Automake release
because `make fetch` failed due to Savannah being crushed under the
scraper horde at an inopportune time?
> 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.
I view it differently: interface compatibility has been (and will be)
preserved. That a specific configuration tuple was deprecated and
declared invalid does not break backwards compatibility. The scripts
are still "drop-in" updates.
-- Jacob
