search

rancher / backup-restore-operator

Apache License 2.0
98 stars 67 forks source link

Add docs about creating a patch release branch #512

Closed mallardduck closed 2 months ago

mallardduck commented 2 months ago

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:

  1. Edit GHA workflows to allow tests/ci to run based on any release/* (or similar) branch regex,
  2. Sync all workflows to older branches via backport.

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)

jbiers commented 2 months ago

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.

mallardduck commented 2 months ago

Just a quick overview to make sure I understand the process proposed here:

  • In a code freeze we of course do not want to merge new code into the release branch. E.g. release/v5.0.
  • But sometimes urgent patches are needed.
  • For that, we create a new branch from release/v5.0 as described in this new doc and merge the desired change into it.
  • A patch release is made from this new branch.
  • When code freeze is over, the change is also merged into the main (release/v5.0) release branch.

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 release/5.0 even if r/r is in a freeze. So we will do that. My impression from recent discussion is that r/r is technically the only thing in freeze.

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.

jbiers commented 2 months ago

LGTM