Proposal: Quarterly releases from main by default
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.
Comments
> it allows us to use CI to build burn in artifacts without publishing them
I think that's a good enough reason to have some complexity.
I'd also like to explore the idea of delaying the publishing/tagging until we pass burn-in. For example, upon committing to main, only publish to jfrog and docker if it's a snapshot version. We can tag one of the snapshot commits for the burn-in if necessary. Then when ready to release, trigger a process that tags and publishes a releasable version number (similar to what we do for docker latest tag ). These changes would probably cost more up-front effort, but avoid having to manage a separate release branch. Need to think more about how we'd handle gradle.properties in this scenario.
In discussions today, the preference is to not build or tag burn-in releases with final version numbers, to prevent inadvertently sending a premature signal that the release is "final".
Today's 23.7.1-RC burn-in release used a
release-23.7.xbranch and a 23.7.1-RC version, no tag was created. This strategy is a bit messy for a cherry-pick and/or hotfix release, but in the normal flow we should have an unbroken chain originating frommainfor a release (albeit the exact release sha will not be part ofmainitself).I propose we change the normal release flow to:
PR to main that updates the change log and the gradle properties to the next SNAPSHOT version.
i.e 23.7.1-SNAPSHOT → 23.7.2-SNAPSHOT, and the corresponding entries in CHANGELOG.MD
once merged, the squashed commit above is merged into the release branch along with a change of the release version to *-RC
i.e. 23.7.2-SNAPSHOT becomes 23.7.1-RC
once burn-in is complete, we merge a single line diff PR that changes 23.7.1-RC to 23.7.1 and the release happens from this branch
This is not as simple as just releasing from
mainBUT it allows us to use CI to build burn in artifacts without publishing them, does not blockmainin any way, and gives a conformed process that for normal releases as well as hotfixes.