Re: Making SRFI go faster Lassi Kortela 25 Apr 2021 21:10 UTC
> 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.