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.:
|
|
|
|
//
|
2021-06-08 23:26:22 +08:00
|
|
|
// 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 sha, e.g.:
|
|
|
|
//
|
|
|
|
// 0.0.0-experimental-a1c2d3e4
|
|
|
|
|
2021-06-08 23:26:22 +08:00
|
|
|
const ReactVersion = '18.0.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.
|
2021-06-08 23:26:22 +08:00
|
|
|
const nextChannelLabel = 'alpha';
|
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 = {
|
|
|
|
'create-subscription': ReactVersion,
|
|
|
|
'eslint-plugin-react-hooks': '4.2.1',
|
|
|
|
'jest-react': '0.12.1',
|
|
|
|
react: ReactVersion,
|
|
|
|
'react-art': ReactVersion,
|
|
|
|
'react-dom': ReactVersion,
|
|
|
|
'react-is': ReactVersion,
|
|
|
|
'react-reconciler': '0.27.0',
|
|
|
|
'react-refresh': '0.11.0',
|
|
|
|
'react-test-renderer': ReactVersion,
|
|
|
|
'use-subscription': '1.6.0',
|
|
|
|
scheduler: '0.21.0',
|
|
|
|
};
|
|
|
|
|
|
|
|
// 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,
|
|
|
|
};
|