Add docs about creating a patch release branch #512
Conversation
|
|
||
| 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. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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. 😄
|
Just a quick overview to make sure I understand the process proposed here:
Is that correct? If not, maybe we can add some extra context into these docs for them to be useful to newcomers to the project who do not yet understand the process very well. |
It's actually kind of the opposite of this 😓 mostly. The idea here being that we should keep working on Repos like ours can follow that freeze, but don't need to strictly. It is however a lot easier to follow the freeze, since working during it needs a process like this in place. And this would roughly be that process to enable us to "branch back in time" and create a clean working slate equivalent to the version we need to patch. |
|
LGTM |
mallardduck
dismissed stale reviews from jbiers and alexandreLamarre
via
59bd6e4
mallardduck
requested review from
ericpromislow
and removed request for
ericpromislow
The goal of adding this doc is so that this repo can have a documented process for this.
In theory with that process laid out for everyone to follow we can continue merging PRs to HEAD branches during r/r freeze with more confidence. And this could potentially allow us more time/flexibility to address the renovate PRs.
Warning
Before we execute on this practice across all our maintained branches we will first need to:
release/*(or similar) branch regex,Eventually we can still adjust how we manage workflows in this repo if that's desired. Since we've been discussing some methods of keeping the workflows in sync across all branches more easily. (Automatic backports, orphan branch of canonical workflows, dedicated workflow repo etc)