This was previously a proposal intends to solve three problems:
...
Monthly feels like a happy medium to aim for.
I think we can and should be flexible though: if there's an important bug, we should release more than once in a month.
I also don't think we should feel compelled to release on a specific date, however mandating once a month seems like it will keep us out of trouble.
...
I think all would agree that there's no release quality improvement gained by having a weeks-long burn-in for the riskier changes.
Several days or a week seems sufficient enough to cover all scenarios, which is what we do for every release now already.
Potential Issues and Feedback
...
to "Replace Quarterly and Bi-Weekly With Monthly Releases" but I think I was putting the cart before the horses: it was proposing one potential specific solution instead of starting a discussion about the problem.
Goal: Make releasing as easy as possible
The main time sink for our releases is cherry-picking. There are two scenarios where we cherry-pick:
- Adding to an existing RC branch during quarterly releases
- Adding hotfixes to a point release
In both cases we have to do this because "unstable" commits are blocking releasing from the main branch.
Suggested Solution: Keep main branch releasable
If we are confident about the stability of the main branch then we can be flexible with our release schedule.
There are many details we could discuss further such as deprecation policy, feature toggles, improved regression testing, and burn-in procedure, but will focus on getting buy-in for the main point of this proposal first.
I will mention one interesting suggestion Gary made that we could treat our (currently internal) burn-in period as a beta release that is announced. We may then gain a better diversity of testing from the community, which is one benefit of the quarterly release candidates.
Discord chat: https://discord.com/channels/905194001349627914/905205502940696607/1085387141460262983
TODO
...