diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml index 05d3bc1f30e4..e4334d05a9c6 100644 --- a/.github/workflows/ci.yml +++ b/.github/workflows/ci.yml @@ -325,11 +325,11 @@ jobs: uses: ./.github/actions/prepare-build - name: Figure out and apply the next canary version - run: npx nx run repo-tools:apply-canary-version + run: OVERRIDE_MAJOR_VERSION=8 npx nx run repo-tools:apply-canary-version - name: Publish all packages to npm with the canary tag # NOTE: this needs to be npx, rather than yarn, to make sure the authenticated npm registry is used - run: npx lerna publish premajor --loglevel=verbose --canary --exact --force-publish --yes --dist-tag rc-v8 + run: npx nx release publish --tag rc-v8 --verbose env: NX_CLOUD_DISTRIBUTED_EXECUTION: false NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }} diff --git a/docs/maintenance/Releases.mdx b/docs/maintenance/Releases.mdx index b26f933ad049..c33b2e841444 100644 --- a/docs/maintenance/Releases.mdx +++ b/docs/maintenance/Releases.mdx @@ -3,8 +3,6 @@ id: releases title: Releases --- - - [Users > Releases](../users/Releases.mdx) describes how our automatic releases are done. There is generally no maintenance activity we need to take for the weekly releases. @@ -26,7 +24,7 @@ Per [Users > Releases > Major Releases](../users/Releases.mdx#major-releases), w - Under `push:` > `branches:` at the beginning of the file, add an `- v${major}` list item. - Add a `publish_canary_version_v${major}` step the same as `publish_canary_version` except: - Change the `if` condition's branch check to: `if: github.ref == 'refs/heads/v${major}'`. - - Its publish command should be `npx lerna publish premajor --loglevel=verbose --canary --exact --force-publish --yes --dist-tag rc-v${major}`. + - Its publish command should be `npx nx release publish --tag rc-v${major} --verbose`. - Merge this into `main` once reviewed and rebase the `v${major}` branch. ### 2. Merging Breaking Changes @@ -34,7 +32,7 @@ Per [Users > Releases > Major Releases](../users/Releases.mdx#major-releases), w 1. Send a PR from `v${major}` to `main` [example: [v6.0.0](https://github.com/typescript-eslint/typescript-eslint/pull/5886)]. 1. Change all [breaking change PRs](https://github.com/typescript-eslint/typescript-eslint/issues?q=is%3Aissue+is%3Aopen+label%3A%22breaking+change%22) to target the `v${major}` branch. - To signify these changes as breaking, the first line of the PR description must read as `BREAKING CHANGE:`, and second line should briefly summarize the changes. - - It is important to note that when merged the commit message must also include `BREAKING CHANGE:` as the first line in order for lerna to recognize it as a breaking change in the release notes. If you miss this it just means more manual work when writing the release documentation. + - It is important to note that when merged the commit message must also include `BREAKING CHANGE:` as the first line in order for nx to recognize it as a breaking change in the release notes. If you miss this it just means more manual work when writing the release documentation. 1. Wait until all required PRs have been merged 1. Let the release wait for **at least 1 week** to allow time for early adopters to help test it and discuss the changes. - Promote it on the [`@tseslint`](https://twitter.com/tseslint) twitter to get some additional attention. @@ -48,7 +46,7 @@ They don't need any special treatment. ### 3. Releasing the Version 1. Discuss with the maintainers to be ready for an [out-of-band](#out-of-band-releases) release. Doing this manually helps ensure someone is on-hand to action any issues that might arise from the major release. -1. Prepare the release notes. Lerna will automatically generate the release notes on GitHub, however this will be disorganized and unhelpful for users. We need to reorganize the release notes so that breaking changes are placed at the top to make them most visible. If any migrations are required, we must list the steps to make it easy for users. +1. Prepare the release notes. nx will automatically generate the release notes on GitHub, however this will be disorganized and unhelpful for users. We need to reorganize the release notes so that breaking changes are placed at the top to make them most visible. If any migrations are required, we must list the steps to make it easy for users. - Example release notes: [`v5.0.0`](https://github.com/typescript-eslint/typescript-eslint/releases/tag/v5.0.0), [`v4.0.0`](https://github.com/typescript-eslint/typescript-eslint/releases/tag/v4.0.0), [`v3.0.0`](https://github.com/typescript-eslint/typescript-eslint/releases/tag/v3.0.0) 1. Finally, tweet the release on the `@tseslint` twitter with a link to the GitHub release. Make sure you include additional information about the highlights of the release! diff --git a/packages/repo-tools/src/apply-canary-version.mts b/packages/repo-tools/src/apply-canary-version.mts index 1be37286cfe5..2696f1ccb061 100644 --- a/packages/repo-tools/src/apply-canary-version.mts +++ b/packages/repo-tools/src/apply-canary-version.mts @@ -2,8 +2,18 @@ import { workspaceRoot } from '@nx/devkit'; import { execaSync } from 'execa'; import semver from 'semver'; +// We are either releasing a canary version of the latest major version, or one for the next major. +const overrideMajorVersion = process.env.OVERRIDE_MAJOR_VERSION; + const preid = 'alpha'; -const distTag = 'canary'; + +let distTag = 'canary'; +if (overrideMajorVersion) { + console.log( + `Overriding canary major version base to v${overrideMajorVersion}`, + ); + distTag = `rc-v${overrideMajorVersion}`; +} const currentLatestVersion = execaSync('npm', [ 'view', @@ -11,11 +21,16 @@ const currentLatestVersion = execaSync('npm', [ 'version', ]).stdout.trim(); -const currentCanaryVersion = execaSync('npm', [ - 'view', - `@typescript-eslint/eslint-plugin@${distTag}`, - 'version', -]).stdout.trim(); +let currentCanaryVersion = null; +try { + currentCanaryVersion = execaSync('npm', [ + 'view', + `@typescript-eslint/eslint-plugin@${distTag}`, + 'version', + ]).stdout.trim(); +} catch { + // (ignored - currentCanaryVersion can be null) +} console.log('\nResolved current versions: ', { currentLatestVersion, @@ -24,28 +39,40 @@ console.log('\nResolved current versions: ', { let nextCanaryVersion: string | null; -if (semver.gte(currentLatestVersion, currentCanaryVersion)) { - console.log( - '\nLatest version is greater than or equal to the current canary version, starting new prerelease base...', - ); - // Determine next minor version above the currentLatestVersion - nextCanaryVersion = semver.inc( - currentLatestVersion, - 'prerelease', - undefined, - preid, - ); +if (overrideMajorVersion) { + nextCanaryVersion = currentCanaryVersion + ? semver.inc(currentCanaryVersion, 'prerelease', undefined, preid) + : semver.inc(currentLatestVersion, 'premajor', undefined, preid); } else { - console.log( - '\nLatest version is less than the current canary version, incrementing the existing prerelease base...', - ); - // Determine next prerelease version above the currentCanaryVersion - nextCanaryVersion = semver.inc( - currentCanaryVersion, - 'prerelease', - undefined, - preid, - ); + if (!currentCanaryVersion) { + throw new Error( + 'An unexpected error occurred, no current canary version could be read from the npm registry', + ); + } + + if (semver.gte(currentLatestVersion, currentCanaryVersion)) { + console.log( + '\nLatest version is greater than or equal to the current canary version, starting new prerelease base...', + ); + // Determine next minor version above the currentLatestVersion + nextCanaryVersion = semver.inc( + currentLatestVersion, + 'prerelease', + undefined, + preid, + ); + } else { + console.log( + '\nLatest version is less than the current canary version, incrementing the existing prerelease base...', + ); + // Determine next prerelease version above the currentCanaryVersion + nextCanaryVersion = semver.inc( + currentCanaryVersion, + 'prerelease', + undefined, + preid, + ); + } } if (!nextCanaryVersion) {
Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.
Alternative Proxies: