This proposal intends to solve three problems:
- Quarterly releases require significant overhead to maintain long-lived release branches, compared to releasing from main.
- Three months is a long time to wait for significant or breaking changes to be released.
- Two weeks is a fast release frequency for users who may find it a burden.
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.
The main benefit of the Quarterly appears to be to allow a notice period for deprecation/breaking changes. This still can be achieved with a monthly cadence by announcing x number of releases before the change is released.
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
From Danno: It should cover a deprecation process then, quarterly was infrequent enough we could break stuff with one prior releases' warning.
Q: Is two months too fast a cadence for deprecation warning -> breaking change?
Danno: I think so, I think we should have quarterly. Stuff like JDK migrations, refactoring user facing APIs in non-compatible ways, etc. (only user facing APIs)
Discord chat: https://discord.com/channels/905194001349627914/905205502940696607/1085387141460262983
TODO
- Define deprecation policy