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.