Scheduled Releases

After the release of 2.2.19, the Dev Team discussed the idea of doing releases on a pre-planned schedule. For 2.2.20, we had planned for the only change to be the addition of the Userguide module as we had just completed a set of new tutorial videos. We didn't stick to this, however, and introduced support of newer PHP versions as well as a new version of Smarty. More on that below.
Although we still like the idea of scheduled releases, we have realized a few problems with it:
Our team of actual coders working on the core is too small. When one person has something come up preventing them from doing the work, there's currently no redundancy to meet a planned deadline.
We aren't being strict enough with what constitutes a patch, minor, or major release (again, more below).
We didn't make it clear enough to the public that the scheduled releases were an experiment.

Bugs

Shortly after releasing 2.2.20, a number of users noticed that sites in certain environments were running into an issue when using template inheritance and assigned content blocks. After a lengthy investigation we discovered two issues that caused this that we'd missed in our internal testing. One was a long-standing Smarty bug being fixed, that had the upshot of some of our older code causing the navigator function to create an infinite loop when editing a page. The second was a bug in the News module upgrade routine that led us away from the previous bug for some time. Both have been addressed in 2.2.21 but may require more thorough improvements in future releases.

Beta Testing and Versioning

Public betas are extremely useful as every user has a unique use-case and server environment. That said, they are also a lot of work to manage as a large percentage of the reported issues are due to unfamiliarity with the system rather than actual new bugs. Because of this, our policy has been to only do public betas on major updates. The problem is, we haven't been strict enough with what constitutes a patch fix, minor, or major update.
Going forward, we plan to stick to a more consistent policy and worry less about tradition when it comes to releases:
0.0.x: bug fix or emergency patch: should not contain any new features, PHP support, Smarty versions, or other library updates unless it's to fix a specific issue. Internal testing only, with three Dev Team members required to approve.
0.x.0: minor update: can include new features and minor library updates. Internal testing with six approvals, or a combination of three internal and at least three semi-public (those who reported the issue, or trusted community members)
x.0.0: major update: traditionally we've only gone to a new major version when it's a near complete refactoring (1.x to 2.x). This has led to changes that should be considered major and needing extensive testing being included in minor and patch releases instead. Going forward, major library changes (e.g. PHP 7 to 8 support) and other big changes should be in a major release. Major releases generally need less backwards-compatibility, so this can actually result in less work for the dev team (e.g. support for older PHP version can be dropped). Major releases will receive public betas of several weeks to months, and patch/minor releases to the previous version may still happen.

In Summary

Please keep in mind we are a small team of volunteers. We do our best, but we make mistakes or decisions you may not agree with. Over the past few years we have adopted a more democratic approach to development and it is working. Our Dev Team meetings are inclusive, we do not tolerate abuse, and we genuinely have fun. We all use CMS Made Simple and want to see it thrive - for a lot of us, our livelihood depends on it. We don't get paid to maintain CMS Made Simple, but we use it in our jobs, side hustles, or personal projects.