Version Strategy

[parkr]

Following up from #4280 (comment), I'd like to discuss regular releases that are documented and predictable. A lot of people use this project and it would build good will in the community if folks could expect regular, steady releases. Humans like predictability.

I'd propose a regular, monthly release. Each month the project cuts a release, unless no changes have been made that month. I'd suggest the first full weekend of each month to keep it stable and predictable. A month also allows lots of time for bug fixing before the next release.

Hot fixes could continue to be released anytime of course, on an as-needed basis.

Releases sometimes are onerous on maintainers so making them regular incentivizes automation and reduction of toil.

[brianmay]

We don't want to make a release if we are not ready for a release. It is likely to be broken if it is forced.

At present time there is a bit of refactoring with build systems and CI, we need to make we get this right.

[JakobLichterfeld]

Unfortunately, the website deployment is not in our hands. Only Adrian has access to the Netifly deployment, which automatically deploys the website with the latest master. We can switch to a different branching strategy to avoid this, but in most cases it is fine to have the latest doc on the website.
The postgres17 is unfortunate. We were aiming for a release the next day, but the refactoring with build and CI was more time consuming than expected, plus we all have other priorities.

That said, we can and will improve. My goal is to have more small releases than big ones. That's why I've automated as many steps as possible, and our CI ensures high quality at all times. And hopefully we have also gotten rid of the space problem with the caches as well.