Skip to content
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

Closed
Romick2005 opened this issue Feb 20, 2023 · 1 comment
Closed

Publish 0.75.0 as latest #931

Romick2005 opened this issue Feb 20, 2023 · 1 comment

Comments

@Romick2005
Copy link

npm outdated
image

Expected 0.75.0 as latest not 0.73.8.

@robhogan
Copy link
Contributor

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
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants