diff --git a/doc/contributing/releases.md b/doc/contributing/releases.md index ac63dec294b5e0..7d53bcdf972962 100644 --- a/doc/contributing/releases.md +++ b/doc/contributing/releases.md @@ -357,6 +357,11 @@ already defined in `src/node_version.h`: #define NODE_MAJOR_VERSION x #define NODE_MINOR_VERSION y #define NODE_PATCH_VERSION z + +// And for alpha releases: +#define NODE_ALPHA_MAJOR_VERSION a +#define NODE_ALPHA_MINOR_VERSION b +#define NODE_ALPHA_PATCH_VERSION c ``` Set the `NODE_VERSION_IS_RELEASE` macro value to `1`. This causes the build to @@ -366,6 +371,14 @@ be produced with a version string that does not have a trailing pre-release tag: #define NODE_VERSION_IS_RELEASE 1 ``` +
+Major version release + +Remove the `NODE_ALPHA_MAJOR_VERSION`, `NODE_ALPHA_MINOR_VERSION`, and +`NODE_ALPHA_PATCH_VERSION` macros. + +
+ ### 4. Update the changelog #### Step 1: Collect the formatted list of changes @@ -825,8 +838,8 @@ project README. On release proposal branch, edit `src/node_version.h` again and: -* Increment `NODE_PATCH_VERSION` by one -* Change `NODE_VERSION_IS_RELEASE` back to `0` +* Increment `NODE_PATCH_VERSION` (or `NODE_ALPHA_PATCH_VERSION` for alpha releases) by one. +* Change `NODE_VERSION_IS_RELEASE` back to `0`. Commit this change with the following commit message format: @@ -893,9 +906,11 @@ git restore --source=upstream/main src/node_version.h On the main branch, instead of reverting changes made to `src/node_version.h` edit it instead and: -* Increment `NODE_MAJOR_VERSION` by one -* Reset `NODE_PATCH_VERSION` to `0` -* Change `NODE_VERSION_IS_RELEASE` back to `0` +* Increment `NODE_MAJOR_VERSION` by one. +* Reset `NODE_PATCH_VERSION` and `NODE_MINOR_VERSION` to `0`. +* Set `NODE_ALPHA_MAJOR_VERSION`, `NODE_ALPHA_MINOR_VERSION`, and + `NODE_ALPHA_PATCH_VERSION` to `0`. +* Change `NODE_VERSION_IS_RELEASE` back to `0`. Amend the current commit to apply the changes: @@ -1194,9 +1209,9 @@ git node release --prepare --startLTS To mark a release line as LTS, the following changes must be made to `src/node_version.h`: -* The `NODE_MINOR_VERSION` macro must be incremented by one -* The `NODE_PATCH_VERSION` macro must be set to `0` -* The `NODE_VERSION_IS_LTS` macro must be set to `1` +* The `NODE_MINOR_VERSION` macro must be incremented by one. +* The `NODE_PATCH_VERSION` macro must be set to `0`. +* The `NODE_VERSION_IS_LTS` macro must be set to `1`. * The `NODE_VERSION_LTS_CODENAME` macro must be set to the code name selected for the LTS release. @@ -1265,15 +1280,15 @@ from cutting a minor or patch release. ### Schedule -New Node.js Major releases happen twice per year: +New Node.js Major releases happen once per year: -* Even-numbered releases are cut in April. -* Odd-numbered releases are cut in October. +* Branch-off is in October. +* Semver-major release is in April. Major releases should be targeted for the third Tuesday of the release month. A major release must not slip beyond the release month. In other words, major -releases must not slip into May or November. +releases must not slip into May. The @nodejs/releasers make a call for releasers 3 months in advance. Currently, this call is automated in the `#nodejs-release-private` @@ -1283,15 +1298,15 @@ The release date for the next major release should be announced immediately following the current release (e.g. the release date for 13.0.0 should be announced immediately following the release of 12.0.0). -### Release branch +### Branch-off -Approximately two months before a major release, new `vN.x` and -`vN.x-staging` branches (where `N` indicates the major release) should be -created as forks of the `main` branch. Up until the cut-off date announced by -the releaser, these must be kept in sync with `main`. +#### Release branch -The `vN.x` and `vN.x-staging` branches must be kept in sync with one another -up until the date of the release. +Approximately six months before a major release, new `vN.x` and +`vN.x-staging` branches (where `N` indicates the major release) should be +created as forks of the `main` branch. Alpha releases should be released picking +up commits from `main`. Target the first alpha release to be released the same +day as the previous release line is graduated to LTS status. If a `SEMVER-MAJOR` pull request lands on the default branch within one month prior to the major release date, it must not be included on the new major @@ -1299,10 +1314,9 @@ staging branch, unless there is consensus from the Node.js releasers team to do so. This measure aims to ensure better stability for the release candidate (RC) phase, which begins approximately two weeks prior to the official release. By restricting `SEMVER-MAJOR` commits in this period, we provide more time for -thorough testing and reduce the potential for major breakages, especially in -LTS lines. +thorough testing and reduce the potential for major breakages. -### Create release labels +#### Create release labels The following issue labels must be created: @@ -1317,7 +1331,40 @@ The label description can be copied from existing labels of previous releases. The label color must be the same for all new labels, but different from the labels of previous releases. -### Release proposal +#### Create the changelog file + +In the `doc/changelogs` directory, create a new `CHANGELOG_V{N}.md` file where +`{N}` is the major version of the release. Follow the structure of the existing +`CHANGELOG_V*.md` files. + +The navigation headers in all of the `CHANGELOG_V*.md` files must be +updated to account for the new `CHANGELOG_V{N}.md` file. + +Once the file is created, the root `CHANGELOG.md` file must be updated to +reference the newly-created major release `CHANGELOG_V{N}.md`. + +#### Generate the changelog + +To generate a proper major release changelog, use the `branch-diff` tool to +compare the `vN.x` branch against the `vN-1.x` branch (e.g. for Node.js 12.0, +we compare the `v12.x` branch against the up to date `v11.x` branch). Make sure +that the local copy of the downlevel branch is up to date. + +The commits in the generated changelog must then be organized: + +* Remove all release commits from the list +* Remove all reverted commits and their reverts +* Separate all SEMVER-MAJOR, SEMVER-MINOR, and SEMVER-PATCH commits into lists + +```console +$ branch-diff upstream/vN-1.x upstream/vN.x --require-label=semver-major --group --filter-release --markdown # get all majors +$ branch-diff upstream/vN-1.x upstream/vN.x --require-label=semver-minor --group --filter-release --markdown # get all minors +$ branch-diff upstream/vN-1.x upstream/vN.x --exclude-label=semver-major,semver-minor --group --filter-release --markdown # get all patches +``` + +### Semver-major release + +#### Release proposal A draft release proposal should be created 6 weeks before the release. A separate `vN.x-proposal` branch should be created that tracks the `vN.x` @@ -1342,7 +1389,7 @@ git push upstream vN.x git push upstream vN.x-staging ``` -### Update `NODE_MODULE_VERSION` +#### Update `NODE_MODULE_VERSION` This macro in `src/node_version.h` is used to signal an ABI version for native addons. It currently has two common uses in the community: @@ -1372,60 +1419,18 @@ see a need to bump `NODE_MODULE_VERSION` outside of a major release then you should consult the TSC. Commits may need to be reverted or a major version bump may need to happen. -### Test releases and release candidates - -Test builds should be generated from the `vN.x-proposal` branch starting at -about 6 weeks before the release. - -Release Candidates should be generated from the `vN.x-proposal` branch starting -at about 4 weeks before the release, with a target of one release candidate -per week. - -Always run test releases and release candidates through the Canary in the -Goldmine tool for additional testing. - ### Changelogs Generating major release changelogs is a bit more involved than minor and patch changelogs. -#### Create the changelog file - -In the `doc/changelogs` directory, create a new `CHANGELOG_V{N}.md` file where -`{N}` is the major version of the release. Follow the structure of the existing -`CHANGELOG_V*.md` files. - -The navigation headers in all of the `CHANGELOG_V*.md` files must be -updated to account for the new `CHANGELOG_V{N}.md` file. - -Once the file is created, the root `CHANGELOG.md` file must be updated to -reference the newly-created major release `CHANGELOG_V{N}.md`. - -#### Generate the changelog - -To generate a proper major release changelog, use the `branch-diff` tool to -compare the `vN.x` branch against the `vN-1.x` branch (e.g. for Node.js 12.0, -we compare the `v12.x` branch against the up to date `v11.x` branch). Make sure -that the local copy of the downlevel branch is up to date. - -The commits in the generated changelog must then be organized: - -* Remove all release commits from the list -* Remove all reverted commits and their reverts -* Separate all SEMVER-MAJOR, SEMVER-MINOR, and SEMVER-PATCH commits into lists - -```console -$ branch-diff upstream/vN-1.x upstream/vN.x --require-label=semver-major --group --filter-release --markdown # get all majors -$ branch-diff upstream/vN-1.x upstream/vN.x --require-label=semver-minor --group --filter-release --markdown # get all minors -$ branch-diff upstream/vN-1.x upstream/vN.x --exclude-label=semver-major,semver-minor --group --filter-release --markdown # get all patches -``` - #### Generate the notable changes For a major release, all SEMVER-MAJOR commits that are not strictly internal, test, or doc-related are to be listed as notable changes. Some SEMVER-MINOR commits may be listed as notable changes on a case-by-case basis. Use your judgment there. +Include the notable changes from the Alpha versions where it applies. ### Update the expected assets diff --git a/src/node_version.h b/src/node_version.h index 4c18037fc8c88a..8c94ce8ec7f34d 100644 --- a/src/node_version.h +++ b/src/node_version.h @@ -31,6 +31,10 @@ #define NODE_VERSION_IS_RELEASE 0 +#define NODE_ALPHA_MAJOR_VERSION 0 +#define NODE_ALPHA_MINOR_VERSION 0 +#define NODE_ALPHA_PATCH_VERSION 0 + #ifndef NODE_STRINGIFY #define NODE_STRINGIFY(n) NODE_STRINGIFY_HELPER(n) #define NODE_STRINGIFY_HELPER(n) #n @@ -41,18 +45,24 @@ #endif #ifndef NODE_TAG -# if NODE_VERSION_IS_RELEASE -# define NODE_TAG "" -# else -# define NODE_TAG "-pre" -# endif +#if NODE_VERSION_IS_RELEASE +#ifdef NODE_ALPHA_MAJOR_VERSION +#define NODE_TAG \ + "-alpha." NODE_STRINGIFY(NODE_ALPHA_MAJOR_VERSION) "." NODE_STRINGIFY( \ + NODE_ALPHA_MINOR_VERSION) "." NODE_STRINGIFY(NODE_ALPHA_PATCH_VERSION) #else +#define NODE_TAG "" +#endif // NODE_ALPHA_MAJOR_VERSION +#else // NODE_VERSION_IS_RELEASE +#define NODE_TAG "-pre" +#endif // NODE_VERSION_IS_RELEASE +#else // NODE_TAG // NODE_TAG is passed without quotes when rc.exe is run from msbuild # define NODE_EXE_VERSION NODE_STRINGIFY(NODE_MAJOR_VERSION) "." \ NODE_STRINGIFY(NODE_MINOR_VERSION) "." \ NODE_STRINGIFY(NODE_PATCH_VERSION) \ NODE_STRINGIFY(NODE_TAG) -#endif +#endif // NODE_TAG # define NODE_VERSION_STRING NODE_STRINGIFY(NODE_MAJOR_VERSION) "." \ NODE_STRINGIFY(NODE_MINOR_VERSION) "." \