As for 0.12, specifically: Things went a bit unplanned. We made promises about a specific feature (two-column floats), but then this feature and preceding refactorings took much longer than anticipated. We should’ve simply broken the promise and cut a release 2 months ago, but we didn’t and then missed that timeframe. Now it’s almost ready and 0.12 will be released soon. We have learned our lesson: Don’t make promises about a specific release and, even if, sometimes it’s better to break the promise than to hold back other features and bug fixes for a long time.
However, with that said, a release cycle of once a week is still unrealistic. A release involves more work than it might seem like: There’s a changelog to be written, the docs need to be reviewed in the rendered version (this often surfaces badly rendering examples), the web app needs to be updated, etc. My release checklist has ~30 steps and often it takes me almost a day. Of course, it would be less work with smaller release, but there’s also simply a constant amount of work and waiting involved.
I think weekly releases would also not make for a good end-user experience. The fact that we can make breaking changes in accordance with SemVer doesn’t make them less annoying for users. Dealing with breaking changes every week would be much more annoying than every 1-2 months, especially for package authors.
Another important point is stability: It’s not uncommon for regressions to sneak into the development version. Those then surface over time and also as part of the “call for testing” we do before releases. Typst 0.12 will also have such a call for testing. This means we can iron out more bugs before they reach most of the users.
Don’t get me wrong: We do agree that the current release cycle is too slow and we want to increase the release frequency after 0.12. But we would still be talking every 6-8 weeks or something like that, not every week. (This is not a promise! :p)