2024-04-19 - Refining the quarterly release system

When I announced at the end of March that I was switching to a Hare-inspired quarterly release scheme with 0.YY.QQ numbering, YY being the year and QQ a zero-indexed quarter, I was aware that this was a little strange, arguably risky, because it didn't really allow for unscheduled bugfixes. I thought maybe I could get away with it by moving very slowly and making small changes. It hasn't taken long for this to backfire somewhat, as it has been pointed out to me that there is a bug in the new formal gemtext speficiation. Specifically, the ABNF specification indicates that a gemtext document consists of either zero or one line of gemtext, when of course it is supposed to be one or more. Thanks to Michael Nordmeyer for bringing this to my attention!

Now, it would probably be relatively safe to just wait until the 0.24.1 release at the end of June to fix this, on the grounds that of course nobody is actually going to deliberately break their clients by changing them to refuse to render documents with more than one line while insisting "this is how it's supposed to be!". But, well, maybe the next silly mistake which slips through will not be so obviously contrary to intention. So here's my hacky solution: the actual quaterly releases will be 0.YY.00 for Q1, 0.YY.10 for Q2, 0.YY.20 for Q3 and 0.YY.30 for Q4. Up to nine 9 bug fixes are then possible between each quarterly release, which hopefully is way more than will ever be needed.

Some might say that this is ugly or stupid or whatever and I won't actually try very hard to deny that. I'm not taking this situation too seriously because I perceive it as profoundly transient. I'm taking the previously announced "Apollo days" goals pretty seriously and I hope to freeze things around 2025-05-08, which is "Apollo 14 day". If that happens, there will only be three more quarterly releases. If that deadline slips and it has to be Apollo 15 day on 2025-11-03, there will only be five more. It's not a lot. We are talking about either a little more than one year of an ugly system in a project which has already existed for close to five and which, importantly, I honestly believe is going to persist for more than a further five. Getting things moving forward again at a steady pace and being able to easily schedule changes and refer to previous versions is enough of a benefit to be worth any small cost that can be realistically attributed to a clunky version system.

So, expect a 0.24.1 release of the gemtext specification fixing this soon.