Errata, PFNs and versioning of SRFIs Marc Nieper-Wißkirchen (27 Oct 2022 15:55 UTC)
Re: Errata, PFNs and versioning of SRFIs Arthur A. Gleckler (27 Oct 2022 18:01 UTC)
Re: Errata, PFNs and versioning of SRFIs Marc Nieper-Wißkirchen (27 Oct 2022 18:25 UTC)
Re: Errata, PFNs and versioning of SRFIs Arthur A. Gleckler (27 Oct 2022 19:12 UTC)
Re: Errata, PFNs and versioning of SRFIs Marc Nieper-Wißkirchen (27 Oct 2022 19:52 UTC)

Re: Errata, PFNs and versioning of SRFIs Marc Nieper-Wißkirchen 27 Oct 2022 18:25 UTC

Am Do., 27. Okt. 2022 um 20:01 Uhr schrieb Arthur A. Gleckler
<xxxxxx@speechcode.com>:
>
> On Thu, Oct 27, 2022 at 8:55 AM Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:
>>
>> Some errata and even more so PFNs imply minor changes of libraries
>> defined in SRFIs.
>>
>> Can we maintain official version numbers (in the form of one to three
>> consecutive natural numbers) for these amendments?
>
> I already maintain Git tags for these purposes, e.g. draft-3, errata-1, final, and even withdrawn. However, I haven't been doing that for post-finalization notes. I've just added a step to my procedures so that I'll do that from now on, e.g. pfn-1.
>
> We shouldn't need any finer detail than that.  In other words, if we need more than one digit and a tag, we're doing something wrong.

The problem with a digit and a tag is that this format cannot be used
in library definitions (when versioning is supported).

Another point I made when referring to semver, and which is not
reflected by a simple digit-and-tag format, is that PFNs introduce
changes of varying severity.  For example, the PFN 146 changes the
semantics because there is no longer a default comparator registered
for mappings.  On the other hand, the PFN of SRFI 124 merely makes a
previously optional identifier compulsory.

For a library consumer, it seems more irrelevant whether a change was
introduced through an erratum or a PFN.