Skip to content

Starting work on a new .Y release

Luke Shumaker edited this page Aug 23, 2022 · 2 revisions

Checklist

  1. Be on the branch (release/vX.Y or master) of the previous release.
  2. Run ./releng/prepare-y-bump; this will create a commit, create some branches, and create some tags; eventually printing something like:
    ======================================================================
    
    All done!
    Look over the commit that has been made locally;
    when you are ready, run the following command to push it:
    
        git push origin release/v2.4 v2.4.0-dev chart/v7.5.0-dev
    
    
  3. Look over the commit and branches and tags that it made (you, as a human, are taking responsibility for them!)
  4. Run that git push command that the script told you to run.

That will have either created a new release/vX.Y for your new version, or updated master for your new version. You can now work on your new version!

Rationale/explanation

  • Git branches: There are 2 modes here
    1. "latest major-version mode": master is always the "latest" branch, so to increment it we need to create a maintenance branch for the version that master has been for up to this point. For example, if we've released 3.1.x, and are now ready to start working on 3.2.0, that means that master was for 3.1.x, but is now going to be for 3.2.0, so we need to create a release/v3.1 branch.
    2. "legacy major-version mode": On the other hand, if we're working on a legacy major-version, then we're already on a named release/vX.Y branch, so we need to create a new release/vX.(Y+1) branch, since re-purposing release/vX.Y would be inappropriate. For example, if we've released 2.3.4, but realize that we need to do a v2.4.0, then we already have a release/v2.3 branch and should create a new release/v2.4 branch from it.
  • Git tags: We use Go (psuedo-)versioning to determine our version numbers. This uses Git tags as the base. By default, Go assumes you're doing a .z bump. So, we create vX.Y.0-dev pre-release tags to tell Go that we're actually doing a .y bump, so that the version numbers of our dev builds approaching the final release have the correct X.Y numbering.
  • Files needing edited:
    • The README.md has an index of all of the release branches; update it to reflect the branch changes explained above.
    • Edit docs/releaseNotes.yml (and then CHANGELOG.md via make generate-fast) to go ahead and create a heading for this next .Y.0 version.
    • Edit the Helm chart's CHANGELOG.md to go ahead and create a heading for this next .Y.0 version.