> On Nov 25, 2022, at 1:37 PM, Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:
>
> Am Fr., 25. Nov. 2022 um 08:00 Uhr schrieb Marc Nieper-Wißkirchen
> <xxxxxx@gmail.com>:
>
> [...]
>
>> I would still prefer numbers (when library versioning is available)
>> because they won't clash with a hypothetical (srfi :999 chapters
>> final) library (i.e. when a version name is actually a library name).
>> With version numbers, we don't have the question of how to order the
>> library name parts, and with names instead of version numbers, we
>> cannot easily express in code "an implementation that covers at least
>> erratum-1".  I still don't see why it shouldn't be possible to have a
>> little version information after each erratum or PFN entry so that
>> implementations can use them if they want.  Alternatively, we can
>> agree on the convention that versions look like (2022 7 19) (for an
>> implementation of everything up to the PFN/erratum added on
>> 2022-07-19). So (srfi :1 (1999 10 9)) implements the original version
>> of SRFI 1, (srfi :1 (2022 10 22)) implements the new specification of
>> reduce-right, and (srfi :1) stays for any version.
>
> The more I think about it, the more I like the idea of optionally
> versioning SRFI implementations using a datum.  The advantages of this
> are the following:  It does not need any new agreement; dates are
> already incorporated into SRFIs.  It goes along well with existing
> mechanisms for library versioning; this includes the monotonicity of
> versions.  It is entirely optional.  When incorporated into a library
> definition, it allows seeing at a glance whether this particular
> implementation has been updated to the newest erratum/PFN.  It is
> orthogonal to SRFI 97 or other naming conventions for libraries.

When a SRFI has been finalized it's spec should be immutable, for the reasons I’ve explained before.  Minor corrections to the text are OK, but not corrections that change the API and functionality.  A small proportion of the SRFIs have not followed that golden rule, so let’s not create an official way to version SRFIs… that would be a step in the wrong direction!  Rather we should ensure that such breaking changes don’t happen again.

Marc