Proposal: Quarterly releases from main by default

Owned by Simon Dudley
Last updated: Aug 01, 2023
1 min read

This is a refinement to the proposal: Avoid Cherry Picked Releases

Goal: Make releasing as easy as possible

Suggested Solution: Don't use RCs for Quarterly releases (by default)

  • We sometimes already do this, for example with 23.7.0.
  • We can still soak for a longer period of time than normal for riskier changes and we can advertise our soak to beta testers if we wish.
  • We can still use a release branch if we feel the need, this proposal just suggests by default  we try to release from main.
  • There is no need for this proposal to change the concept or versioning of quarterly releases and what they might signal (more significant changes).

What needs to change?

Some sort of notification about upcoming breaking changes, the obvious place being in the changelog/release notes ahead of the change landing.

Suggested Deprecation Policy

  • Have an "Upcoming breaking changes" section in the changelog, which announces features that are upcoming, e.g. a warning about big changes in the next quarterly release.
  • Time it needs to be in changelog before releasing is at maintainers' discretion.
  • Feature/branch/PR management of upcoming feature is at maintainers' discretion.
  • Optionally add target release/date.