Suggestion: Regression only releases. 2-4 weeks after real release

We’ve all seen it. A pre release is sent out, and a couple of people get back about tests. All good to go right? Then the real release is done…

And 1000x more people try it out, and lots of issues start rolling in. Many of them regressions, or tiny fixes that are required to build on modern OS versions (or old ones we aren’t using anymore).
?%?!!! fuck! Why didn’t they try the pre-release? Well, many people only try the real releases, because… reasons. Some of those are because package maintainers set up their systems to only take released versions.

A partial solution? Quick follow up releases, with regression only fixes(or mostly regression fixes). Release early, release often as they say. After a release, start fixing the various problems, and then do another release soon after (2-4 weeks is ok).

But releases take lots of effort? True. But, if a release is done soon after the last one, much of the work is easier… because people remember stuff, and little things that stop releases over time haven’t happened yet. Also, it’s a good opportunity to automate and document something of the release process in each release, and swap release managers each time to reduce the burden.

Just an idea that’s worked ok on some other projects.

2 Likes

The SDL developers are already trying out a 3 month release cycle, as of 2.0.10’s release.

You can see the planned release deadline here: https://libsdl.org/next.php
And bugs that are intended to be fixed by then, here: https://libsdl.org/todo.php

Aside from that, if there’s a regression that’s fixed in the source code but isn’t in a released version yet, you can always get SDL’s latest source and build it on your own.