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.
  • No labels

2 Comments

  1. Gary Schulte

    • We can still use a release branch if we feel the need, this proposal just suggests  by default  we try to release from main.


    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.x  branch 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 from main  for a release (albeit the exact release sha will not be part of main  itself).


    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 main  BUT it allows us to use CI to build burn in artifacts without publishing them, does not block main in any way, and gives a conformed process that for normal releases as well as hotfixes.


    1. Simon Dudley

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