Add single source of truth for package versions #21608
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
facebook-github-bot
added
CLA Signed
React Core Team
acdlite
force-pushed
the
prepare-new-next-versioning-scheme
branch
4 times, most recently
from
1d1b04a
to
e285c50
Compare
|
Comparing: 86715ef...8ae4805 Critical size changesIncludes critical production bundles, as well as any change greater than 2%:
Significant size changesIncludes any change greater than 0.2%: (No significant changes) |
acdlite
force-pushed
the
prepare-new-next-versioning-scheme
branch
from
e285c50
to
8ae4805
Compare
facebook-github-bot
pushed a commit
to facebook/react-native
that referenced
this pull request
Jun 7, 2021
Summary: - **[0eea57724](facebook/react@0eea57724 )**: Fix typo in comment (accumlated → accumulated) ([#21637](facebook/react#21637)) //<ithinker5>// - **[0706162ba](facebook/react@0706162ba )**: Fix typo in comment (environement → environment) ([#21635](facebook/react#21635)) //<niexq>// - **[9d17b562b](facebook/react@9d17b562b )**: Fix typo in comment (satsify → satisfy) ([#21629](facebook/react#21629)) //<niexq>// - **[b610fec00](facebook/react@b610fec00 )**: fix comments: expiration time -> lanes ([#21551](facebook/react#21551)) //<Shannon Feng>// - **[cc4d24ab0](facebook/react@cc4d24ab0 )**: [Fizz] Always call flush() if it exists ([#21625](facebook/react#21625)) //<Dan Abramov>// - **[e0d9b2899](facebook/react@e0d9b2899 )**: [Fizz] Minor Fixes for Warning Parity ([#21618](facebook/react#21618)) //<Sebastian Markbåge>// - **[1b7b3592f](facebook/react@1b7b3592f )**: [Fizz] Implement Component Stacks in DEV for warnings ([#21610](facebook/react#21610)) //<Sebastian Markbåge>// - **[39f007489](facebook/react@39f007489 )**: Make enableSuspenseLayoutEffectSemantics static for www ([#21617](facebook/react#21617)) //<Brian Vaughn>// - **[8f3794276](facebook/react@8f3794276 )**: Prepare semver (`latest`) releases in CI ([#21615](facebook/react#21615)) //<Andrew Clark>// - **[8b4201535](facebook/react@8b4201535 )**: Devtools: add feature to trigger an error boundary ([#21583](facebook/react#21583)) //<Bao Pham>// - **[154a8cf32](facebook/react@154a8cf32 )**: Fix reference to wrong variable //<Andrew Clark>// - **[6736a38b9](facebook/react@6736a38b9 )**: Add single source of truth for package versions ([#21608](facebook/react#21608)) //<Andrew Clark>// - **[86715efa2](facebook/react@86715efa2 )**: Resolve the true entry point during tests ([#21505](facebook/react#21505)) //<Sebastian Markbåge>// - **[a8a4742f1](facebook/react@a8a4742f1 )**: Convert ES6/TypeScript/CoffeeScript Tests to createRoot + act ([#21598](facebook/react#21598)) //<Sebastian Markbåge>// - **[1d3558965](facebook/react@1d3558965 )**: Disable deferRenderPhaseUpdateToNextBatch by default ([#21605](facebook/react#21605)) //<Sebastian Markbåge>// - **[a8964649b](facebook/react@a8964649b )**: Delete an unused field ([#21415](facebook/react#21415)) //<okmttdhr>// - **[76f85b3e5](facebook/react@76f85b3e5 )**: Expose Fizz in stable builds ([#21602](facebook/react#21602)) //<Dan Abramov>// - **[e16d61c30](facebook/react@e16d61c30 )**: [Offscreen] Mount/unmount layout effects ([#21386](facebook/react#21386)) //<Andrew Clark>// - **[63091939b](facebook/react@63091939b )**: OSS feature flag updates ([#21597](facebook/react#21597)) //<Brian Vaughn>// - **[efbd69b27](facebook/react@efbd69b27 )**: Define global __WWW__ = true flag during www tests ([#21504](facebook/react#21504)) //<Sebastian Markbåge>// - **[28625c6f4](facebook/react@28625c6f4 )**: Disable strict effects for legacy roots (again) ([#21591](facebook/react#21591)) //<Brian Vaughn>// - **[3c2341416](facebook/react@3c2341416 )**: Update jest to v26 ([#21574](facebook/react#21574)) //<Sebastian Silbermann>// - **[0d493dcda](facebook/react@0d493dcda )**: Removed _debugID field from Fiber - Issue #21558 ([#21570](facebook/react#21570)) //<Pulkit Sharma>// - **[7841d0695](facebook/react@7841d0695 )**: Enable the updater-tracking feature flag in more builds ([#21567](facebook/react#21567)) //<Brian Vaughn>// - **[6405efc36](facebook/react@6405efc36 )**: Enabled Profiling feature flags for OSS release ([#21565](facebook/react#21565)) //<Brian Vaughn>// Changelog: [General][Changed] - React Native sync for revisions 2d8d133...0eea577 jest_e2e[run_all_tests] Reviewed By: bvaughn Differential Revision: D28932083 fbshipit-source-id: 012c1bfb857ed59d7283334d633f1cce8ec50360
koto
pushed a commit
to koto/react
that referenced
this pull request
Jun 15, 2021
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.
koto
pushed a commit
to koto/react
that referenced
this pull request
Jun 15, 2021
Follow-up to facebook#21608
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The versioning scheme for
@nextreleases 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@nextis not as volatile. It represents the next stable release. So, I think we can afford to include an actual version number at the beginning of the string instead of0.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.jsthat acts as the single source of truth for every package's version. The build script uses this module to build the@nextpackages.In the future, I want to start building the
@latestpackages the same way we do@nextand@experimental. (What we do now is download a@nextrelease 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.