-
Notifications
You must be signed in to change notification settings - Fork 626
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Publish 0.75.0 as latest #931
Comments
Thanks for spotting this! Fixed |
facebook-github-bot
pushed a commit
that referenced
this issue
Sep 20, 2023
… allow prerelease tags (#1086) Summary: Currently, when we `npm publish --workspaces` on tag creation, NPM implicitly tags with "latest". This is fine in the regular release flow, but when we release a hotfix (a patch release on an old minor, from a release branch) the tag is incorrect. This causes issues that some folks notice within minutes: #931, #1057. Currently, it has to be manually corrected using `dist-tag` on each package after publishing. This adds some logic in CircleCI to automatically tag with `latest` explicitly *only if* the tag is present on `main`, and not on any release branch (of the form `0.79.x`). OTOH, if the release looks like a hotfix (present on a release branch but *not* on `main`) we tag with the release branch name. There is no way in NPM not to have any dist-tag, so specifying *something* is the only way to prevent it assuming `latest`. If the release is ambiguous (edge case: we go back and tag a common ancestor of `main` and `0.123.x` with `v0.123.0-alpha`) the publish aborts. Pull Request resolved: #1086 Test Plan: - Tested (after many iterations!) at my fork https://github.com/robhogan/metro, eg https://app.circleci.com/pipelines/github/robhogan/metro/74/workflows/5a375202-5863-43fd-b633-4a983b0ed4b8/jobs/264 - I'm about to run a hotfix release to pull some bug fixes back for RN 0.72, so that'll be the first "live" test. Reviewed By: huntie Differential Revision: D49461403 Pulled By: robhogan fbshipit-source-id: 26fd37d90ccae9d2125e9ef1cc8ba538ee6beb85
robhogan
added a commit
that referenced
this issue
Jan 29, 2024
… allow prerelease tags (#1086) Summary: Currently, when we `npm publish --workspaces` on tag creation, NPM implicitly tags with "latest". This is fine in the regular release flow, but when we release a hotfix (a patch release on an old minor, from a release branch) the tag is incorrect. This causes issues that some folks notice within minutes: #931, #1057. Currently, it has to be manually corrected using `dist-tag` on each package after publishing. This adds some logic in CircleCI to automatically tag with `latest` explicitly *only if* the tag is present on `main`, and not on any release branch (of the form `0.79.x`). OTOH, if the release looks like a hotfix (present on a release branch but *not* on `main`) we tag with the release branch name. There is no way in NPM not to have any dist-tag, so specifying *something* is the only way to prevent it assuming `latest`. If the release is ambiguous (edge case: we go back and tag a common ancestor of `main` and `0.123.x` with `v0.123.0-alpha`) the publish aborts. Pull Request resolved: #1086 Test Plan: - Tested (after many iterations!) at my fork https://github.com/robhogan/metro, eg https://app.circleci.com/pipelines/github/robhogan/metro/74/workflows/5a375202-5863-43fd-b633-4a983b0ed4b8/jobs/264 - I'm about to run a hotfix release to pull some bug fixes back for RN 0.72, so that'll be the first "live" test. Reviewed By: huntie Differential Revision: D49461403 Pulled By: robhogan fbshipit-source-id: 26fd37d90ccae9d2125e9ef1cc8ba538ee6beb85
robhogan
added a commit
that referenced
this issue
Jan 30, 2024
… allow prerelease tags (#1086) Summary: Currently, when we `npm publish --workspaces` on tag creation, NPM implicitly tags with "latest". This is fine in the regular release flow, but when we release a hotfix (a patch release on an old minor, from a release branch) the tag is incorrect. This causes issues that some folks notice within minutes: #931, #1057. Currently, it has to be manually corrected using `dist-tag` on each package after publishing. This adds some logic in CircleCI to automatically tag with `latest` explicitly *only if* the tag is present on `main`, and not on any release branch (of the form `0.79.x`). OTOH, if the release looks like a hotfix (present on a release branch but *not* on `main`) we tag with the release branch name. There is no way in NPM not to have any dist-tag, so specifying *something* is the only way to prevent it assuming `latest`. If the release is ambiguous (edge case: we go back and tag a common ancestor of `main` and `0.123.x` with `v0.123.0-alpha`) the publish aborts. Pull Request resolved: #1086 Test Plan: - Tested (after many iterations!) at my fork https://github.com/robhogan/metro, eg https://app.circleci.com/pipelines/github/robhogan/metro/74/workflows/5a375202-5863-43fd-b633-4a983b0ed4b8/jobs/264 - I'm about to run a hotfix release to pull some bug fixes back for RN 0.72, so that'll be the first "live" test. Reviewed By: huntie Differential Revision: D49461403 Pulled By: robhogan fbshipit-source-id: 26fd37d90ccae9d2125e9ef1cc8ba538ee6beb85
robhogan
added a commit
that referenced
this issue
Jan 30, 2024
… allow prerelease tags (#1086) Summary: Currently, when we `npm publish --workspaces` on tag creation, NPM implicitly tags with "latest". This is fine in the regular release flow, but when we release a hotfix (a patch release on an old minor, from a release branch) the tag is incorrect. This causes issues that some folks notice within minutes: #931, #1057. Currently, it has to be manually corrected using `dist-tag` on each package after publishing. This adds some logic in CircleCI to automatically tag with `latest` explicitly *only if* the tag is present on `main`, and not on any release branch (of the form `0.79.x`). OTOH, if the release looks like a hotfix (present on a release branch but *not* on `main`) we tag with the release branch name. There is no way in NPM not to have any dist-tag, so specifying *something* is the only way to prevent it assuming `latest`. If the release is ambiguous (edge case: we go back and tag a common ancestor of `main` and `0.123.x` with `v0.123.0-alpha`) the publish aborts. Pull Request resolved: #1086 Test Plan: - Tested (after many iterations!) at my fork https://github.com/robhogan/metro, eg https://app.circleci.com/pipelines/github/robhogan/metro/74/workflows/5a375202-5863-43fd-b633-4a983b0ed4b8/jobs/264 - I'm about to run a hotfix release to pull some bug fixes back for RN 0.72, so that'll be the first "live" test. Reviewed By: huntie Differential Revision: D49461403 Pulled By: robhogan fbshipit-source-id: 26fd37d90ccae9d2125e9ef1cc8ba538ee6beb85
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
npm outdated
Expected 0.75.0 as latest not 0.73.8.
The text was updated successfully, but these errors were encountered: