> 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:
@@@
Given a version number MAJOR.MINOR.PATCH, increment the:
MAJOR version when you make incompatible API changes
MINOR version when you add functionality in a backward compatible
manner
PATCH version when you make backward compatible bug fixes
Additional labels for pre-release and build metadata are available as
extensions to the MAJOR.MINOR.PATCH format.
@@@Removing the Windows platform tuple is neither a "backward compatible bug fix" nor a "functionality [added] in a backward compatible manner."
> 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.
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.
> 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? The updates to the stamp and the release ceremony can all be automated away using git hooks and shell scripts. See the following quote from the page you linked:
> In most cases, following published standards is convenient for usersAll 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.
-- With Valediction, Kamila Szewczyk (https://iczelia.net) On 10/26/26 2:49 AM, Jacob Bachmeyer wrote:
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
OpenPGP_0xC868F0B6DE38409D.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
