On 10/26/26 07:13, Kamila Szewczyk wrote:
> 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.
If you break downstream software, no matter whether through interface
incompatibility or not, per SemVer you have to bump the major version:
[...]
Removing the Windows platform tuple is neither a "backward compatible
bug fix" nor a "functionality [added] in a backward compatible manner."
Then we do not use SemVer for GNU config; it is that simple...
...and GNU config does *not* use SemVer, instead simply keeping
last-modified datestamps in the scripts.
> I did say "(anymore?)" and your counter-example is from seven years
> ago and was fixed in less than three hours.
Why deprive oneself of being able to make mistakes and fixing them on
short notice by not having a proper release schedule?
One more example of `robust, release-ready, dependable, etc., from
every possible git checkout' GNU config being broken is a commit from
28 June 2020, 5e531d391852a54e7fab2d8ff55625fca514b305; it breaks
three things -- nto-qnx, emx, arm-uclinux-uclibcgnueabi; fixed 107
days later.
Regarding "was fixed in less than three hours" -- I can name examples
when the fix was not so quick, but arguably these are just plain old
bugs that have nothing to do with having a release schedule.
Exactly: the catastrophic syntax error that broke config.guess on all
systems was discovered and fixed promptly. There is (now?) a testsuite
that would catch such an error very quickly, although contributors and
the maintainer must remember to run it.
A less-obvious issue affecting only some platforms is an ordinary bug.
Releases generally ship with bugs, too.
I am bringing up these to demonstrate that we are all human and make
mistakes. The impact of these mistakes on downstream can be greatly
reduced. We should strive to make the entirety of our software
collection more dependable.
That is exactly why we support "drop-in" updates of config.guess and
config.sub: a bad version, even bundled into a released package, can be
easily fixed by the user simply downloading a newer version. Script
timestamps are entirely sufficient for this.
Note also that a catastrophic bug, like the syntax error you cite, would
also be caught by any maintainer of a package using GNU Automake running
`make distcheck` before publishing a release.
> 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>)
Why would we interfere with external packaging, when we can avoid that
at near-zero cost to end users and ourselves?
I see no interference here; only third parties seeking to impose their
"One True Way" by refusing to support alternatives. Datestamps as
version numbers are a long-standing, albeit minority, practice.
The updates to the stamp and the release ceremony can all be automated
away using git hooks and shell scripts.
The timestamp is already updated automatically if Emacs is used to edit
the file, as I understand it.
See the following quote from the page you linked:
> In most cases, following published standards is convenient for users
All of my arguments boil down to (essentially) good modern software
engineering practice and nothing more. Whoever wants to depend on git
checkouts is welcome to (at their own peril -- as usual), as to avoid
breaking compatibility.
Yes, but that does *not* mean that published standards are (or should
be) straitjackets upon GNU.
I posit that "Do it this way or third-party programs will break." is not
a valid argument at the GNU Project, established backwards compatibility
excepted. We make our own decisions and third-parties can deal with
it. We put especially little weight on other people's notions of "One
True Way".
-- Jacob
