> 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.