Am Fr., 25. Nov. 2022 um 23:31 Uhr schrieb Marc Feeley
<xxxxxx@iro.umontreal.ca>:
>
> > 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.

I didn't say that I wanted some kind of versioning just to have
versioning.  My point is that versioning is needed when the specs de
facto do not stay immutable.  As the process is currently run, there
are changes or recommendations to changes.

It seems to me that we haven't reached a consensus about how to handle
the question of immutability in the future.  There are (at least) the
following options:

1. Finalized SRFIs are immutable.  No errata that would change the
meaning of a correct implementation are allowed.  (This seems to be
along Lassi's thinking: some things will be broken, just don't use
them.)
2. Errata can be applied to finalized SRFIs where an erratum can fix
the text or the API when it becomes clear that the author's intention
isn't correctly described.  (This does not allow fixing a broken
design.)
3. Like 2. but also PFNs are allowed to be attached to finalized
SRFIs.  (These are often in the form of recommendations.)

The current practice seems to be 3.

For both 2. and 3., what is implemented by implementations of the same
SRFI will differ.  In these cases, some kind of versioning is needed;
otherwise, a portable program would only be able to use an
intersection of features, but even this intersection could shrink over
time.

I think that 3. works (and has worked), but we need a way to document
and test which version a particular implementation supports.  If we
agree on 1. (given the smallness of our group I am not sure whether we
can be that strict), ignore all my requests about adding official
versions/tags.