Backporting

What to backport

We only backport bug-fixes. New features will not be backported. There is a 'needs backport' label which can be applied to a PR against master. Usually backports are created once the origin PR is merged. The reason for this is that you'd have to adjust your backport everytime something changes in the origin PR which is error-prone and can get confusing very quickly.

How to backport

If you want to open a 'backport' for a given PR, you should follow some conventions

Example PR:

"fix a bug in module_x"

ID = 1000

1 - Create a named branch from the target branch (e.g. SES5)

Create a branch:

(wip)backport-$pulrequest_id

2 - Cherry-picking

Find the sha of your commits in the original pull request and perform:

$ git cherry-pick -x $sha

3 - Create the pullrequest

After pushing the branch etc, please open a pullrequest against the target branch.

Github will autofill the subject and the body of the PR when you select the target PR in the dropdown menu.

Please make sure you follow the naming conventions. The backport should be named like that:

[backport][$target_branch] Name_of_the_original_PR

To the prefilled body, please add a reference to the original PR:

backport of #$ID

Labels

When the backport pullrequest is merged, the 'needs backport' label can be removed from the original pullrequest.

Internal bug referencing

When the bug has any other mentions in a different bug tracking system, please add a small reference to the body.

Tracker A: bug_number

Milestones

You don't need to assign any milestone to the backport.

Irregular backporting (Exceptions)

When there is no master pullrequest to cherry-pick from, please add a proper description in the PR body.