First, thank you to everyone participating in this discussion. It is an important one.
This reply turned into a bit of a State-of-the-SRFI essay, but I was trying to address some issues that come into play in the versioning question. Sorry it's so long. I hope it will still contribute.
The SRFI process has changed a bit since I took over as editor in 2015. Some of that change has been deliberate, and some has been accidental. Some of the changes have had unintended consequences.
I've been lax about the ninety-day deadline for several reasons.
First, the discussions on the SRFI mailing lists are often excellent, and cutting them off to meet an arbitrary deadline risks forcing authors to make bad design choices, or to ignore feedback. SRFIs can often be made better through extra discussion, and that discussion is often going strong at the ninety-day point.
Second, we're all volunteers, and it's sometimes just too hard to find the time for all the work required to revise a document in response to so much feedback.
Third, no other place on the net seems to have become the place where ideas for Scheme features were discussed in detail and with so much care. If Lassi's Scheme Review proposal becomes reality, this might change.
There have been a few results from this change in policy, some good and some bad:
SRFIs are being proposed, and even finalized, at a faster rate than ever before, and the quality is still high. This isn't entirely because the deadline has been relaxed, but that's at least a factor.
Some SRFIs have dragged on for far too long — over a year, in some cases. In most cases, fruitful discussion has continued, and the author has provided new drafts. In others, the author has stopped responding for months at a time, or has made promises to continue work, but hasn't followed through. I've had to resort to declaring a SRFI withdrawn, or threatening to do so, neither of which is easy for someone like me, who doesn't like conflict.
I formalized the errata process. Before that, fixes to SRFIs were sometimes published, with notes in the Status section of the document, but the rules weren't clear, at least to me. I've had to revise that process to account for the fact that some authors have gone incommunicado, but the basic idea is the same as what I believe was the informal policy under previous editors.
I've added a new way for SRFIs to become withdrawn: if the author of a new SRFI B proposes a replacement for an earlier finalized SRFI A, and A's author agrees, A may be withdrawn in favor of B. In that case, I add a note in A's See Also section referring readers to B.
I introduced the idea of the Post-Finalization Note, or PFN. These are notes added to the Status section when the author finds a mistake or wants to make a clarification, but that note doesn't fit the criteria for an erratum. This may be one of those things that seems like a good idea at the time, and is good for an individual SRFI's implementers and users, but sets a precedent that is ultimately detrimental to the process. I'm not sure.
I added the requirement that tests be included with the sample implementation. This is standard practice in the field today, and wasn't when SRFI started.
It's almost certainly true that authors are now proposing more experimental SRFIs, i.e. ones that haven't been in use in a Scheme implementation for a long time. That may be partly because of the longer discussion periods, but it may also be because of the relationship with R7RS Large.
There may be another cause. The SRFI process document strictly limits the editor's responses to a new SRFI submitted by an author:
The response may be a request to clarify, justify, or withdraw the proposal. Such a request must not reflect the personal bias of an editor. Rather, it will be made strictly to maintain a high quality of submissions.
The high quality of submissions is open to interpretation, but my reading of those sentences leads me to think that I should accept clearly written SRFIs document offered in good faith that conform to the basic requirements, and that I shouldn't turn away proposals just because my sense is that they're too new.
In any case, having more experimental SRFIs has been both good and bad. There have been some great SRFIs that were based on ideas that hadn't already been thoroughly tried out, but there have also been some that have been finalized perhaps before they were ready.
There are now many SRFIs with portable implementations. Because R6RS and R7RS Small standardized library systems, it became easier than ever to implement a portable implementation of a new SRFI, building on the work of earlier standards and SRFIs, and working around the quirks of specific implementations, e.g. using cond-expand. Having tests has made porting SRFI implementations easier, too.
Increasingly, adding a SRFI to a Scheme implementation is often something that a user can do without the help of the Scheme implementation's maintainers. Even if the maintainers are involved, they may not have to interpret the language of the SRFI carefully, instead concentrating their efforts on porting the sample code.
I've made mistakes. Despite my best efforts, I haven't always followed the SRFI process correctly or consistently, and I've missed typos, spelling errors, self-contradictory statements, and crucial mistakes and omissions in finalized SRFIs. One consequence of this is that some SRFIs have changed since they were finalized.
While I don't like the idea of making versions a first-class part of the SRFI process, I will mention that I have made a git tag for every erratum that has been published since I became editor, e.g. erratum-1. I haven't done that for post-finalization notes, but I plan to add pfn-1 and so on from now on. Any SRFI implementer is free to incorporate those tags into their library names, e.g. by using (srfi 1) for compatibility, but using the second name (srfi 1
erratum-5) (or an R6RS-compatible equivalent) for precision.
Being SRFI editor is sometimes overwhelming, but it's so rewarding to see so much passionate care put into my favorite programming language by so many brilliant people. I love working on my own Scheme implementation, but facilitating other people's work on Scheme is the biggest contribution I can make.
Thanks to you all for keeping the discussion so civil and productive, even when there is strong disagreement.