Lines Matching +full:sync +full:- +full:branches

10 * [Who can make a release?](#who-can-make-a-release)
11   * [1. Jenkins release access](#1-jenkins-release-access)
12   * [2. <nodejs.org> access](#2-nodejsorg-access)
13   * [3. A publicly listed GPG key](#3-a-publicly-listed-gpg-key)
14 * [How to create a release](#how-to-create-a-release)
15   * [0. Pre-release steps](#0-pre-release-steps)
16   * [1. Update the staging branch](#1-update-the-staging-branch)
17   * [2. Create a new branch for the release](#2-create-a-new-branch-for-the-release)
18   * [3. Update `src/node_version.h`](#3-update-srcnode_versionh)
19   * [4. Update the changelog](#4-update-the-changelog)
20   * [5. Create release commit](#5-create-release-commit)
21   * [6. Propose release on GitHub](#6-propose-release-on-github)
22   * [7. Ensure that the release branch is stable](#7-ensure-that-the-release-branch-is-stable)
23   * [8. Produce a nightly build _(optional)_](#8-produce-a-nightly-build-optional)
24   * [9. Produce release builds](#9-produce-release-builds)
25   * [10. Test the build](#10-test-the-build)
26   * [11. Tag and sign the release commit](#11-tag-and-sign-the-release-commit)
27   * [12. Set up for the next release](#12-set-up-for-the-next-release)
28   * [13. Cherry-pick the release commit to `master`](#13-cherry-pick-the-release-commit-to-master)
29   * [14. Push the release tag](#14-push-the-release-tag)
30   * [15. Promote and sign the release builds](#15-promote-and-sign-the-release-builds)
31   * [16. Check the release](#16-check-the-release)
32   * [17. Create a blog post](#17-create-a-blog-post)
33   * [18. Create the release on GitHub](#18-create-the-release-on-github)
34   * [19. Cleanup](#19-cleanup)
35   * [20. Announce](#20-announce)
36   * [21. Celebrate](#21-celebrate)
37 * [LTS releases](#lts-releases)
38 * [Major releases](#major-releases)
50 **[node-test-pull-request](https://ci.nodejs.org/job/node-test-pull-request/)**
51 is used for a final full-test run to ensure that the current *HEAD* is stable.
54 **[iojs+release](https://ci-release.nodejs.org/job/iojs+release/)** can be used
60 **[iojs+release](https://ci-release.nodejs.org/job/iojs+release/)** does all of
85 ### 3. A publicly-listed GPG key
93 The GPG keys should be fetchable from a known third-party keyserver. The SKS
94 Keyservers at <https://sks-keyservers.net> are recommended. Use the
96 do an ASCII-armored export of your key first:
99 $ gpg --armor --export email@server.com > ~/nodekey.asc
105 $ gpg --keyserver pool.sks-keyservers.net --recv-keys <FINGERPRINT>
117 * Dates listed below as _"YYYY-MM-DD"_ should be the date of the release **as
118   UTC**. Use `date -u +'%Y-%m-%d'` to find out what this is.
123 ### 0. Pre-release steps
135 properly tested, run a `node-test-pull-request` job against the `master` branch
136 of the `nodejs-private/node-private` repository a day or so before the
146 $ git checkout v1.x-staging
147 $ git reset --hard upstream/v1.x-staging
153 … label](https://github.com/nodejs/node/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-desc+label%3Av8.x).
163 When landing the PR add the `Backport-PR-URL:` line to each commit. Close the
165 `backport-requested-vN.x` to `backported-to-vN.x`.
168 [`branch-diff`](https://github.com/nodejs/branch-diff). The tool is available on
170 metadata, as well as the GitHub labels such as `semver-minor` and
171 `semver-major`. One drawback is that when the `PR-URL` metadata is accidentally
178 …-diff v1.x-staging master --exclude-label=semver-major,semver-minor,dont-land-on-v1.x,backport-req…
182 cherry-picked.
186 * Checking for errors (incorrect `PR-URL`)
187 * Checking semver status - Commits labeled as `semver-minor` or `semver-major`
188 should only be cherry-picked when appropriate for the type of release being
191 `baking-for-lts` tag.
193 When you are ready to cherry-pick commits, you can automate with the following
194 command. (For semver-minor releases, make sure to remove the `semver-minor` tag
195 from `exclude-label`.)
198 …-diff v1.x-staging master --exclude-label=semver-major,semver-minor,dont-land-on-v1.x,backport-req…
201 When cherry-picking commits, if there are simple conflicts you can resolve
202 them. Otherwise, add the `backport-requested-vN.x` label to the original PR
205  Lines](https://github.com/nodejs/node/blob/HEAD/doc/guides/backporting-to-release-lines.md)" guide.
207 If commits were cherry-picked in this step, check that the test still pass.
213 Then, push to the staging branch to keep it up-to-date.
216 $ git push upstream v1.x-staging
221 Create a new branch named `vx.y.z-proposal`, off the corresponding staging
225 $ git checkout -b v1.2.3-proposal upstream/v1.x-staging
240 be produced with a version string that does not have a trailing pre-release tag:
251 [`changelog-maker`](https://github.com/nodejs/changelog-maker) to do this:
254 $ changelog-maker --group
257 `changelog-maker` counts commits since the last tag and if the last tag
259 `--start-ref` argument:
262 $ changelog-maker --group --filter-release --start-ref v1.2.2
265 `--filter-release` will remove the release commit from the previous release.
281 ## YYYY-MM-DD, Version x.y.z (Release Type), @releaser
298 You can use `branch-diff` to get a list of commits with the `notable-change`
302 $ branch-diff upstream/v1.x v1.2.3-proposal --require-label=notable-change -format=simple
326 sed -i "s/REPLACEME/$VERSION/g" doc/api/*.md` or `perl -pi -e "s/REPLACEME/$VERSION/g" doc/api/*.md
345 YYYY-MM-DD, Version x.y.z (Release Type)
349 * Copy the notable changes list here, reformatted for plain-text
354 [distribution indexer](https://github.com/nodejs/nodejs-dist-indexer) to
358 YYYY-MM-DD, Version x.y.z (Release Type)
364 * Copy the notable changes list here, reformatted for plain-text
370 release branches to more easily be passed between members of the release team if
374 `v5.3.0-proposal` PR should target `v5.x`, not master. Paste the CHANGELOG
392 good place to @-mention the relevant contributors.
394 After opening the PR, update the release commit to include `PR-URL` metadata and
395 force-push the proposal.
399 Run a **[`node-test-pull-request`](https://ci.nodejs.org/job/node-test-pull-request/)**
403 Also run a **[`node-test-commit-v8-linux`](https://ci.nodejs.org/job/node-test-commit-v8-linux/)**
406 Perform some smoke-testing. There is the
407 **[`citgm-smoker`](https://ci.nodejs.org/job/citgm-smoker/)** CI job for this
416 **[iojs+release](https://ci-release.nodejs.org/job/iojs+release/)** and wait for
426 Use **[iojs+release](https://ci-release.nodejs.org/job/iojs+release/)** to
462 tag and pushed it to GitHub, you ***must not*** delete and re-tag. If you make
463 a mistake after tagging then you'll have to version-bump and start again and
467 -v v6.0.0`. The message should look something like `2016-04-26 Node.js v6.0.0
470 Install `git-secure-tag` npm module:
473 $ npm install -g git-secure-tag
479 $ git secure-tag <vx.y.z> <commit-sha> -sm "YYYY-MM-DD Node.js vx.y.z (<release-type>) Release"
482 `release-type` is either "Current" or "LTS". For LTS releases, you should also
486 2019-10-22 Node.js v10.17.0 'Dubnium' (LTS) Release
504 PR-URL: <full URL to your release proposal PR>
508 version number _and_ a pre-release tag.
515 $ git merge --ff-only v1.2.3-proposal
517 $ git checkout v1.x-staging
519 $ git push upstream v1.x-staging
522 ### 13. Cherry-pick the release commit to `master`
526 $ git cherry-pick v1.x^
533 $ git checkout --ours HEAD -- src/node_version.h
541 Then finish cherry-picking and push the commit upstream:
545 $ git cherry-pick --continue
550 **Do not** cherry-pick the "Working on vx.y.z" commit to `master`.
580 The key can be loaded either with `ssh-add`:
584 $ ssh-add ~/.ssh/node_id_rsa
591 $ ./tools/release.sh -i ~/.ssh/node_id_rsa
599 to: `gpg --list-secret-keys` to list your keys. If you don't have any keys, it
605 along with the list of artifacts. It will use the `dist-promotable` command on
611 release. The command on the server will be similar to: `dist-promote vx.y.z`.
620 --default-key YOURKEY --digest-algo SHA256 --clearsign /path/to/SHASUMS256.txt`.
625 similar to: `gpg --default-key YOURKEY --digest-algo SHA256 --detach-sign /path/to/SHASUMS256.txt`.
633 **It is possible to only sign a release by running `./tools/release.sh -s
651 Create a new blog post by running the [nodejs.org release-post.js script][].
665 * Always use pull-requests on the [nodejs.org repository][]. Be respectful
666   of the website team, but you do not have to wait for PR sign-off. Please
727 -#define NODE_MINOR_VERSION 12
728 -#define NODE_PATCH_VERSION 1
732 -#define NODE_VERSION_IS_LTS 0
733 -#define NODE_VERSION_LTS_CODENAME ""
737 -#define NODE_VERSION_IS_RELEASE 0
741 The changes must be made as part of a new semver-minor release.
745 The `lts-watch-vN.x` issue label must be created, with the same color as other
749 `backport-requested-vN.x` label must be deleted.
760 * Even-numbered releases are cut in April.
761 * Odd-numbered releases are cut in October.
775 `vN.x-staging` branches (where `N` indicates the major release) should be
777 date, these must be kept in sync with `master` and must not be considered to
778 be stable branches (e.g. they may be force pushed).
780 The `vN.x` and `vN.x-staging` branches must be kept in sync with one another
783 One month or less before the release date, commits must be cherry-picked into
784 the two branches. To land `SEMVER-MAJOR` at this time requires no objections
792 * `backport-blocked-vN.x`
793 * `backport-open-vN.x`
794 * `backport-requested-vN.x`
795 * `backported-to-vN.x`
796 * `dont-land-on-vN.x`
805 separate `vN.x-proposal` branch should be created that tracks the `vN.x`
819   [NAN](https://github.com/nodejs/nan) uses it to form a compatibility-layer for
821 * Determining the ABI for downloading pre-built binaries of native addons, e.g.
822   [node-pre-gyp](https://github.com/mapbox/node-pre-gyp) uses this value as
824   binary to download at install-time.
827 and also if there are non-trivial API changes. The rules are not yet strictly
836 `-pre` suffix for the major version being prepared.
845 Test builds should be generated from the `vN.x-proposal` branch starting at
848 Release Candidates should be generated from the `vN.x-proposal` branch starting
870 reference the newly-created major release `CHANGELOG_V{N}.md`.
874 To generate a proper major release changelog, use the `branch-diff` tool to
875 compare the `vN.x` branch against the `vN-1.x` branch (e.g. for Node.js 12.0,
883 * Separate all SEMVER-MAJOR, SEMVER-MINOR, and SEMVER-PATCH commits into lists
887 For a major release, all SEMVER-MAJOR commits that are not strictly internal,
888 test, or doc-related are to be listed as notable changes. Some SEMVER-MINOR
889 commits may be listed as notable changes on a case-by-case basis. Use your
902 …: https://github.com/nodejs/build/blob/HEAD/doc/jenkins-guide.md#restricting-access-for-security-r…
904 [Partner Communities]: https://github.com/nodejs/community-committee/blob/HEAD/governance/PARTNER_C…
906 [nodejs.org release-post.js script]: https://github.com/nodejs/nodejs.org/blob/HEAD/scripts/release…