react/ReactVersions.js

58 lines
1.5 KiB
JavaScript
Raw Normal View History

Add single source of truth for package versions (#21608) The versioning scheme for `@next` releases does not include semver information. Like `@experimental`, the versions are based only on the hash, i.e. `0.0.0-<commit_sha>`. The reason we do this is to prevent the use of a tilde (~) or caret (^) to match a range of prerelease versions. For `@experimental`, I think this rationale still makes sense — those releases are very unstable, with frequent breaking changes. But `@next` is not as volatile. It represents the next stable release. So, I think we can afford to include an actual verison number at the beginning of the string instead of `0.0.0`. We can also add a label that indicates readiness of the upcoming release, like "alpha", "beta", "rc", etc. To prepare for this the new versioning scheme, I updated the build script. However, **this PR does not enable the new versioning scheme yet**. I left a TODO above the line that we'll change once we're ready. We need to specify the expected next version numbers for each package, somewhere. These aren't encoded anywhere today — we don't specify version numbers until right before publishing to `@latest`, using an interactive script: `prepare-release-from-npm`. Instead, what we can do is track these version numbers in a module. I added `ReactVersions.js` that acts as the single source of truth for every package's version. The build script uses this module to build the `@next` packages. In the future, I want to start building the `@latest` packages the same way we do `@next` and `@experimental`. (What we do now is download a `@next` release from npm and swap out its version numbers.) Then we could run automated tests in CI to confirm the packages are releasable, instead of waiting to verify that right before publish.
2021-06-03 11:54:26 +08:00
'use strict';
// This module is the single source of truth for versioning packages that we
// publish to npm.
//
// Packages will not be published unless they are added here.
//
// The @latest channel uses the version as-is, e.g.:
//
// 18.0.0
//
// The @next channel appends additional information, with the scheme
// <version>-<label>-<commit_sha>, e.g.:
//
// 18.0.0-alpha-a1c2d3e4
Add single source of truth for package versions (#21608) The versioning scheme for `@next` releases does not include semver information. Like `@experimental`, the versions are based only on the hash, i.e. `0.0.0-<commit_sha>`. The reason we do this is to prevent the use of a tilde (~) or caret (^) to match a range of prerelease versions. For `@experimental`, I think this rationale still makes sense — those releases are very unstable, with frequent breaking changes. But `@next` is not as volatile. It represents the next stable release. So, I think we can afford to include an actual verison number at the beginning of the string instead of `0.0.0`. We can also add a label that indicates readiness of the upcoming release, like "alpha", "beta", "rc", etc. To prepare for this the new versioning scheme, I updated the build script. However, **this PR does not enable the new versioning scheme yet**. I left a TODO above the line that we'll change once we're ready. We need to specify the expected next version numbers for each package, somewhere. These aren't encoded anywhere today — we don't specify version numbers until right before publishing to `@latest`, using an interactive script: `prepare-release-from-npm`. Instead, what we can do is track these version numbers in a module. I added `ReactVersions.js` that acts as the single source of truth for every package's version. The build script uses this module to build the `@next` packages. In the future, I want to start building the `@latest` packages the same way we do `@next` and `@experimental`. (What we do now is download a `@next` release from npm and swap out its version numbers.) Then we could run automated tests in CI to confirm the packages are releasable, instead of waiting to verify that right before publish.
2021-06-03 11:54:26 +08:00
//
// The @experimental channel doesn't include a version, only a date and a sha, e.g.:
Add single source of truth for package versions (#21608) The versioning scheme for `@next` releases does not include semver information. Like `@experimental`, the versions are based only on the hash, i.e. `0.0.0-<commit_sha>`. The reason we do this is to prevent the use of a tilde (~) or caret (^) to match a range of prerelease versions. For `@experimental`, I think this rationale still makes sense — those releases are very unstable, with frequent breaking changes. But `@next` is not as volatile. It represents the next stable release. So, I think we can afford to include an actual verison number at the beginning of the string instead of `0.0.0`. We can also add a label that indicates readiness of the upcoming release, like "alpha", "beta", "rc", etc. To prepare for this the new versioning scheme, I updated the build script. However, **this PR does not enable the new versioning scheme yet**. I left a TODO above the line that we'll change once we're ready. We need to specify the expected next version numbers for each package, somewhere. These aren't encoded anywhere today — we don't specify version numbers until right before publishing to `@latest`, using an interactive script: `prepare-release-from-npm`. Instead, what we can do is track these version numbers in a module. I added `ReactVersions.js` that acts as the single source of truth for every package's version. The build script uses this module to build the `@next` packages. In the future, I want to start building the `@latest` packages the same way we do `@next` and `@experimental`. (What we do now is download a `@next` release from npm and swap out its version numbers.) Then we could run automated tests in CI to confirm the packages are releasable, instead of waiting to verify that right before publish.
2021-06-03 11:54:26 +08:00
//
// 0.0.0-experimental-241c4467e-20200129
Add single source of truth for package versions (#21608) The versioning scheme for `@next` releases does not include semver information. Like `@experimental`, the versions are based only on the hash, i.e. `0.0.0-<commit_sha>`. The reason we do this is to prevent the use of a tilde (~) or caret (^) to match a range of prerelease versions. For `@experimental`, I think this rationale still makes sense — those releases are very unstable, with frequent breaking changes. But `@next` is not as volatile. It represents the next stable release. So, I think we can afford to include an actual verison number at the beginning of the string instead of `0.0.0`. We can also add a label that indicates readiness of the upcoming release, like "alpha", "beta", "rc", etc. To prepare for this the new versioning scheme, I updated the build script. However, **this PR does not enable the new versioning scheme yet**. I left a TODO above the line that we'll change once we're ready. We need to specify the expected next version numbers for each package, somewhere. These aren't encoded anywhere today — we don't specify version numbers until right before publishing to `@latest`, using an interactive script: `prepare-release-from-npm`. Instead, what we can do is track these version numbers in a module. I added `ReactVersions.js` that acts as the single source of truth for every package's version. The build script uses this module to build the `@next` packages. In the future, I want to start building the `@latest` packages the same way we do `@next` and `@experimental`. (What we do now is download a `@next` release from npm and swap out its version numbers.) Then we could run automated tests in CI to confirm the packages are releasable, instead of waiting to verify that right before publish.
2021-06-03 11:54:26 +08:00
const ReactVersion = '18.2.0';
Add single source of truth for package versions (#21608) The versioning scheme for `@next` releases does not include semver information. Like `@experimental`, the versions are based only on the hash, i.e. `0.0.0-<commit_sha>`. The reason we do this is to prevent the use of a tilde (~) or caret (^) to match a range of prerelease versions. For `@experimental`, I think this rationale still makes sense — those releases are very unstable, with frequent breaking changes. But `@next` is not as volatile. It represents the next stable release. So, I think we can afford to include an actual verison number at the beginning of the string instead of `0.0.0`. We can also add a label that indicates readiness of the upcoming release, like "alpha", "beta", "rc", etc. To prepare for this the new versioning scheme, I updated the build script. However, **this PR does not enable the new versioning scheme yet**. I left a TODO above the line that we'll change once we're ready. We need to specify the expected next version numbers for each package, somewhere. These aren't encoded anywhere today — we don't specify version numbers until right before publishing to `@latest`, using an interactive script: `prepare-release-from-npm`. Instead, what we can do is track these version numbers in a module. I added `ReactVersions.js` that acts as the single source of truth for every package's version. The build script uses this module to build the `@next` packages. In the future, I want to start building the `@latest` packages the same way we do `@next` and `@experimental`. (What we do now is download a `@next` release from npm and swap out its version numbers.) Then we could run automated tests in CI to confirm the packages are releasable, instead of waiting to verify that right before publish.
2021-06-03 11:54:26 +08:00
// The label used by the @next channel. Represents the upcoming release's
// stability. Could be "alpha", "beta", "rc", etc.
const nextChannelLabel = 'next';
Add single source of truth for package versions (#21608) The versioning scheme for `@next` releases does not include semver information. Like `@experimental`, the versions are based only on the hash, i.e. `0.0.0-<commit_sha>`. The reason we do this is to prevent the use of a tilde (~) or caret (^) to match a range of prerelease versions. For `@experimental`, I think this rationale still makes sense — those releases are very unstable, with frequent breaking changes. But `@next` is not as volatile. It represents the next stable release. So, I think we can afford to include an actual verison number at the beginning of the string instead of `0.0.0`. We can also add a label that indicates readiness of the upcoming release, like "alpha", "beta", "rc", etc. To prepare for this the new versioning scheme, I updated the build script. However, **this PR does not enable the new versioning scheme yet**. I left a TODO above the line that we'll change once we're ready. We need to specify the expected next version numbers for each package, somewhere. These aren't encoded anywhere today — we don't specify version numbers until right before publishing to `@latest`, using an interactive script: `prepare-release-from-npm`. Instead, what we can do is track these version numbers in a module. I added `ReactVersions.js` that acts as the single source of truth for every package's version. The build script uses this module to build the `@next` packages. In the future, I want to start building the `@latest` packages the same way we do `@next` and `@experimental`. (What we do now is download a `@next` release from npm and swap out its version numbers.) Then we could run automated tests in CI to confirm the packages are releasable, instead of waiting to verify that right before publish.
2021-06-03 11:54:26 +08:00
const stablePackages = {
'eslint-plugin-react-hooks': '4.6.0',
'jest-react': '0.14.0',
Add single source of truth for package versions (#21608) The versioning scheme for `@next` releases does not include semver information. Like `@experimental`, the versions are based only on the hash, i.e. `0.0.0-<commit_sha>`. The reason we do this is to prevent the use of a tilde (~) or caret (^) to match a range of prerelease versions. For `@experimental`, I think this rationale still makes sense — those releases are very unstable, with frequent breaking changes. But `@next` is not as volatile. It represents the next stable release. So, I think we can afford to include an actual verison number at the beginning of the string instead of `0.0.0`. We can also add a label that indicates readiness of the upcoming release, like "alpha", "beta", "rc", etc. To prepare for this the new versioning scheme, I updated the build script. However, **this PR does not enable the new versioning scheme yet**. I left a TODO above the line that we'll change once we're ready. We need to specify the expected next version numbers for each package, somewhere. These aren't encoded anywhere today — we don't specify version numbers until right before publishing to `@latest`, using an interactive script: `prepare-release-from-npm`. Instead, what we can do is track these version numbers in a module. I added `ReactVersions.js` that acts as the single source of truth for every package's version. The build script uses this module to build the `@next` packages. In the future, I want to start building the `@latest` packages the same way we do `@next` and `@experimental`. (What we do now is download a `@next` release from npm and swap out its version numbers.) Then we could run automated tests in CI to confirm the packages are releasable, instead of waiting to verify that right before publish.
2021-06-03 11:54:26 +08:00
react: ReactVersion,
'react-art': ReactVersion,
'react-dom': ReactVersion,
'react-is': ReactVersion,
'react-reconciler': '0.29.0',
'react-refresh': '0.14.0',
Add single source of truth for package versions (#21608) The versioning scheme for `@next` releases does not include semver information. Like `@experimental`, the versions are based only on the hash, i.e. `0.0.0-<commit_sha>`. The reason we do this is to prevent the use of a tilde (~) or caret (^) to match a range of prerelease versions. For `@experimental`, I think this rationale still makes sense — those releases are very unstable, with frequent breaking changes. But `@next` is not as volatile. It represents the next stable release. So, I think we can afford to include an actual verison number at the beginning of the string instead of `0.0.0`. We can also add a label that indicates readiness of the upcoming release, like "alpha", "beta", "rc", etc. To prepare for this the new versioning scheme, I updated the build script. However, **this PR does not enable the new versioning scheme yet**. I left a TODO above the line that we'll change once we're ready. We need to specify the expected next version numbers for each package, somewhere. These aren't encoded anywhere today — we don't specify version numbers until right before publishing to `@latest`, using an interactive script: `prepare-release-from-npm`. Instead, what we can do is track these version numbers in a module. I added `ReactVersions.js` that acts as the single source of truth for every package's version. The build script uses this module to build the `@next` packages. In the future, I want to start building the `@latest` packages the same way we do `@next` and `@experimental`. (What we do now is download a `@next` release from npm and swap out its version numbers.) Then we could run automated tests in CI to confirm the packages are releasable, instead of waiting to verify that right before publish.
2021-06-03 11:54:26 +08:00
'react-test-renderer': ReactVersion,
'use-subscription': '1.8.0',
'use-sync-external-store': '1.2.0',
scheduler: '0.23.0',
Add single source of truth for package versions (#21608) The versioning scheme for `@next` releases does not include semver information. Like `@experimental`, the versions are based only on the hash, i.e. `0.0.0-<commit_sha>`. The reason we do this is to prevent the use of a tilde (~) or caret (^) to match a range of prerelease versions. For `@experimental`, I think this rationale still makes sense — those releases are very unstable, with frequent breaking changes. But `@next` is not as volatile. It represents the next stable release. So, I think we can afford to include an actual verison number at the beginning of the string instead of `0.0.0`. We can also add a label that indicates readiness of the upcoming release, like "alpha", "beta", "rc", etc. To prepare for this the new versioning scheme, I updated the build script. However, **this PR does not enable the new versioning scheme yet**. I left a TODO above the line that we'll change once we're ready. We need to specify the expected next version numbers for each package, somewhere. These aren't encoded anywhere today — we don't specify version numbers until right before publishing to `@latest`, using an interactive script: `prepare-release-from-npm`. Instead, what we can do is track these version numbers in a module. I added `ReactVersions.js` that acts as the single source of truth for every package's version. The build script uses this module to build the `@next` packages. In the future, I want to start building the `@latest` packages the same way we do `@next` and `@experimental`. (What we do now is download a `@next` release from npm and swap out its version numbers.) Then we could run automated tests in CI to confirm the packages are releasable, instead of waiting to verify that right before publish.
2021-06-03 11:54:26 +08:00
};
// These packages do not exist in the @next or @latest channel, only
// @experimental. We don't use semver, just the commit sha, so this is just a
// list of package names instead of a map.
const experimentalPackages = [
'react-fetch',
'react-fs',
'react-pg',
'react-server-dom-webpack',
];
module.exports = {
ReactVersion,
nextChannelLabel,
stablePackages,
experimentalPackages,
};