...
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