From 1d49b8cc52042b83d7c5a6ad814d98803409d859 Mon Sep 17 00:00:00 2001 From: Pierre Sassoulas Date: Fri, 6 Jan 2023 21:21:03 +0100 Subject: Bump astroid to 2.13.0, update changelog --- doc/release.md | 21 ++++++++++++++------- 1 file changed, 14 insertions(+), 7 deletions(-) (limited to 'doc') diff --git a/doc/release.md b/doc/release.md index d9bc628c..83cc55d2 100644 --- a/doc/release.md +++ b/doc/release.md @@ -44,13 +44,20 @@ Check the commit and then push to a release branch ## Backporting a fix from `main` to the maintenance branch -Whenever a commit on `main` should be released in a patch release on the current -maintenance branch we cherry-pick the commit from `main`. - -- During the merge request on `main`, make sure that the changelog is for the patch - version `X.Y-1.Z'`. (For example: `v2.3.5`) -- After the PR is merged on `main` cherry-pick the commits on the `maintenance/X.Y.x` - branch (For example: from `maintenance/2.4.x` cherry-pick a commit from `main`) +Whenever a PR on `main` should be released in a patch release on the current maintenance +branch: + +- Label the PR with `backport maintenance/X.Y-1.x`. (For example + `backport maintenance/2.3.x`) +- Squash the PR before merging (alternatively rebase if there's a single commit) +- (If the automated cherry-pick has conflicts) + - Add a `Needs backport` label and do it manually. + - You might alternatively also: + - Cherry-pick the changes that create the conflict if it's not a new feature before + doing the original PR cherry-pick manually. + - Decide to wait for the next minor to release the PR + - In any case upgrade the milestones in the original PR and newly cherry-picked PR + to match reality. - Release a patch version ## Releasing a patch version -- cgit v1.2.1