Define process for PR backports and make backports a prerequisite in the release guide

[shashankram]

Please describe the Improvement and/or Feature Request Based on the discussion, it seems like a good idea to define a documented process regarding PRs that need to be backported to one or more release branches.

This document would describe the process to backport changes going into main that need to be backported to one or more release branches.

Proposal

1. PR author requests that a PR made to main be backported to prior release branches. The maintainers determine whether the fix is applicable to prior released versions and if a patch fix is necessary for the bug being fixed. Additionally, it's the maintainer's responsibility to question if a specific PR should be backported to a prior release version, and may request the author of the PR to do so, in addition to adding the backport-to/release=<vMajor.Minor> label to the PR. The maintainer may backport the PR themself if the author does not backport the necessary PR.
2. The release guide notes that PRs labeled with the backport-to/.release=... label are backported prior to cutting the release tags and the final release. If this can be automated, even better, but manual verification must be required at the very least. This ensures backporting PRs is a pre-release criterion.

Scope (please mark with X where applicable)

• Project Release [X]

[keithmattix]

Note from an offline convo I had with @steeling: when backporting for a patch, perhaps we should use a staging branch of sorts so that all of the proposed changes live in one place, are applied in one PR and are thus revertable in one PR.

[shashankram]

Note from an offline convo I had with @steeling: when backporting for a patch, perhaps we should use a staging branch of sorts so that all of the proposed changes live in one place, are applied in one PR and are thus revertable in one PR.

Wondering what's the use case for such a workflow. It would be an additional overhead to maintain a staging branch just for backports, and I haven't seen such a branching strategy commonly used.

We could still add backports in a single PR, but I'd rather have PRs backported in a timely manner versus doing it all towards the end of the release.

[keithmattix]

Oh I didn't mean to maintain a long-lived staging branch; just once we've decided to create a patch for a backport, we make PRs into a holding area so we can backport all the work into the release branch into 1 PR

[shashankram]

Oh I didn't mean to maintain a long-lived staging branch; just once we've decided to create a patch for a backport, we make PRs into a holding area so we can backport all the work into the release branch into 1 PR

I understood your suggestion, but unsure about the need for such a staging branch. I'd rather backport PRs at the time of merge to main vs queuing them all to merge them in 1 PR. I don't see a benefit in doing so, as the branch itself is staging the commit until the release is cut.

What's your reasoning for wanting a staging branch?

[keithmattix]

The use case I was thinking of was being able to return the release-branch to its previous state relatively easily, but a git checkout commithash + a PR will usually accomplish the same end result. Feel free to disregard

[github-actions[bot]]

This issue will be closed due to a long period of inactivity. If you would like this issue to remain open then please comment or update.

[github-actions[bot]]

Issue closed due to inactivity.