There are a few possible approaches to stability. Yearly stable releases
is one of them, but that's still moving very slowly.
Yes, yearly is quite slow, but I was trying to be realistic about how
much we can do :) If a stable release comes with a spec, that adds some
writing effort that is not fun to do several times a year while the
interface is changing.
Another possible
approach is something like Semantic Versioning: have rules about when
the version of each module changes, and include that version in the
module name.
So instead of something like (scheme-live string) you'd have
(scheme-live string 1), and then if someone made a breaking change to
the API (removed or renamed a procedure, changed the number of arguments
to a procedure, etc.), the new change would have to be (scheme-live
string 2), and the old version would still exist. Then updates won't
break existing code.
This is good otherwise, but locks in the module boundaries; it doesn't
provide a natural way to decide that adding a particular module was a
mistake, or that the module should have a different name.
Sweeping module changes across stable versions may be a sign that
something's wrong with the design mentality (I'm still not sure whether
or not it's a problem) but module boundary changes in the unstable
version over the course of a year sound like they'd make a lot of sense.
If there are stable versions at fixed intervals (e.g. yearly) that ought
to be automatically SemVer compatible: version 2021 is followed by
version 2022, then 2023, etc.
