Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add docs about creating a patch release branch #512

Merged
merged 6 commits into from
Jul 31, 2024
Merged

Add docs about creating a patch release branch #512

Changes from 1 commit
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
76c43c7
Add docs about creating a patch release branch
mallardduck Jul 24, 2024
53e31d7
fix typo
mallardduck Jul 24, 2024
f270805
typos
mallardduck Jul 24, 2024
90e5cd2
expand doc to addresss what and why too
mallardduck Jul 24, 2024
55bebdf
Add example command for push similar to prior steps
mallardduck Jul 25, 2024
59bd6e4
typos
mallardduck Jul 26, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
36 changes: 36 additions & 0 deletions docs/creating-a-patch-release-branch.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,36 @@
## Creating a patch release branch

This doc will cover the how's and when's of creating a minor release branch for BRO.
Ideally for this repo we will not create these before we need them to reduce branch noise.
So in this repo "patch release branch" should only be created JIT, not preemptively.

### Why would I create a patch release branch?
Technically repos like ours do not have to withhold progress due to the main rancher/rancher code-freeze.
So in theory we can continue merging to our release branch as we please during a release freeze.

Unfortunately, if PRs are merged and need to create a last minute patch release the HEAD branch is no longer valid for this.
As cutting a release from that would include more changes than the small fix a last minute patch would require.

In that event, you would need to create a `release/vX.Y.(Z+1)` branch where all values are defined based on the version being patched.
This new patch release branch would be created based on the original tag being patched.
Finally, you will backport the fix from the HEAD release branch to this patch release branch.

### How do I create a patch release branch?

Best demonstrated by example, lets assume we need to patch BRO `v5.0.0` and don't want any new changes in `release/v5.0`.
How do we make those moves?

1. Start by checking out the tag being patched: ```git checkout tags/v5.0.0```
2. Now create a new patch branch from this spot: ```git checkout -b release/v5.0.1```
3. Push the new patch branch to the BRO repo.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm unclear on step 3. We don't want to modify release/v5.0 , so we now have to make a release for it as well, right? But from branch release/v5.0.1 ? And the PR will normally be made from a fork, but approving it means basically transferring it from the fork to the rancher/BRO repo, right?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So step 3 may vary depending on your local git repo which is why I excluded it.

But this would literally be the action of git push - and i my specific local repo I would do: git push upstream (since that's the upstream that points to rancher/bro not mallardduck/bro).

After steps 1 and 2 - your local git is: a) already at local branch release/v5.0.1 and b) that branch matches the commit of release v5.0.0. Those two together give us the same end result as if we were to have created release/v5.0.1 right at the same time as releasing tag v5.0.0.

Copy link
Member Author

@mallardduck mallardduck Jul 24, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can add that as an example and put a note about making sure you know what your local git repo's remotes are named and to use yours?

Updated the docs to expand on this example and put a clear note about updating the example commands. 😄


Once the new branch is pushed to Rancher remote repo you should PR a backport to it.

In general treat this the same way as a normal release branch for older release versions.
Meaning we should only backport to these branches and never forward-port to from them to others.
mallardduck marked this conversation as resolved.
Show resolved Hide resolved

### How do I release from a patch release branch?

Follow the normal process however, the only version that we will ever release from the branch is the one it mathces.
mallardduck marked this conversation as resolved.
Show resolved Hide resolved
In the example above, we should only produce `v5.0.1` based releases (alphas, betas, RCs, and stable).
The patch release branch should not be used to produce any other release versions.