lib/*.js
(assert
, buffer
, etc.)build
doc
lib / src
test
tools
There may be more than one subsystem valid for any particular issue or pull request.
confirmed-bug
- Bugs you have verified existdiscuss
- Things that need larger discussionfeature request
- Any issue that requests a new feature (usually not PRs)good first issue
- Issues suitable for newcomers to processmeta
- For issues whose topic is governance, policies, procedures, etc.tsc-agenda
- Open issues and pull requests with this label will be added to the Technical Steering Committee meeting agendasemver-{minor,major}
be conservative – that is, if a change has the remote chance of breaking something, go for semver-major
when adding a semver label, add a comment explaining why you're adding it
minor vs. patch: roughly: “does it add a new method / does it add a new section to the docs”
major vs. everything else: run last versions tests against this version, if they pass, probably minor or patch
A breaking change helper (full source):
SHOW=$(git show-ref -d $(git describe --abbrev=0) | tail -n1 | awk '{print $1}') git checkout $(git show -s --pretty='%T' $SHOW) -- test make -j4 test
We use labels to keep track of which branches a commit should land on:
dont-land-on-v?.x
land-on-v?.x
backport-requested-v?.x
dont-land-on-v?.x
or backported-to-v?.x
backported-to-v?.x
lts-watch-v?.x
lts-agenda
v?.x
master
but rather the v?.x-staging
branchOnce a release line enters maintenance mode, the corresponding labels do not need to be attached anymore, as only important bugfixes will be included.
macos
, windows
, smartos
, aix
arm
, mips
, s390
, ppc