From b440e8e4e480e71d43eee3f1fadcf4e07886296b Mon Sep 17 00:00:00 2001 From: Anna Henningsen Date: Sat, 15 Apr 2017 22:05:00 +0200 Subject: doc: describe labelling process for backports Based on discussion from the first backporting team meeting. PR-URL: https://github.com/nodejs/node/pull/12431 Reviewed-By: Benjamin Gruenbaum Reviewed-By: James M Snell Reviewed-By: Myles Borins --- doc/onboarding-extras.md | 31 +++++++++++++++++++++++++++---- 1 file changed, 27 insertions(+), 4 deletions(-) (limited to 'doc/onboarding-extras.md') diff --git a/doc/onboarding-extras.md b/doc/onboarding-extras.md index d19a73091f..400b5ea406 100644 --- a/doc/onboarding-extras.md +++ b/doc/onboarding-extras.md @@ -80,6 +80,33 @@ Please use these when possible / appropriate git checkout $(git show -s --pretty='%T' $(git show-ref -d $(git describe --abbrev=0) | tail -n1 | awk '{print $1}')) -- test; make -j4 test ``` +### LTS/Version labels + +We use labels to keep track of which branches a commit should land on: + +* `dont-land-on-v?.x` + * For changes that do not apply to a certain release line + * Also used when the work of backporting a change outweighs the benefits +* `land-on-v?.x` + * Used by releasers to mark a PR as scheduled for inclusion in an LTS release + * Applied to the original PR for clean cherry-picks, to the backport PR otherwise +* `backport-requested-v?.x` + * Used to indicate that a PR needs a manual backport to a branch in order to land the changes on that branch + * Typically applied by a releaser when the PR does not apply cleanly or it breaks the tests after applying + * Will be replaced by either `dont-land-on-v?.x` or `backported-to-v?.x` +* `backported-to-v?.x` + * Applied to PRs for which a backport PR has been merged +* `lts-watch-v?.x` + * Applied to PRs which the LTS working group should consider including in a LTS release + * Does not indicate that any specific action will be taken, but can be effective as messaging to non-collaborators +* `lts-agenda` + * For things that need discussion by the LTS working group + * (for example semver-minor changes that need or should go into an LTS release) +* `v?.x` + * Automatically applied to changes that do not target `master` but rather the `v?.x-staging` branch + +Once a release line enters maintenance mode, the corresponding labels do not +need to be attached anymore, as only important bugfixes will be included. ### Other Labels @@ -89,10 +116,6 @@ Please use these when possible / appropriate * Architecture labels * `arm`, `mips`, `s390`, `ppc` * No x86{_64}, since that is the implied default -* `lts-agenda`, `lts-watch-v*` - * tag things that should be discussed to go into LTS or should go into a specific LTS branch - * (usually only semver-patch things) - * will come more naturally over time ## Updating Node.js from Upstream -- cgit v1.2.3