Closed pgsandstrom closed 2 weeks ago
According to semver 2 pre-release versions are supposed to be ordered by dot-separated string ordering
These versions are not ordered. Consumers of canary or rc-*
versions are not supposed to use any ranges (^
, ~
, >
etc.).
If you want to get the latest RC, you can use npm view react@rc --json versio n
I dont quite understand what you mean by "these versions are not ordered". Are there instances where an older version would have a newer date string? If not, than at least our issue would be resolved by my suggestion.
I understand that it would be strange to use ranges with an rc version. I also understand that npm has tags that can be used to find canary/next/rc versions. But that is not directly related to my issue.
The basic gist is: According to semver precedence of pre-releases must be determined by string ordering. It would help us if React complied with semver.
Are there instances where an older version would have a newer date string?
Meaning they're not ordered in a SemVer sense. If your application works with one Canary version, there's no "later" version that has any guarantees whether it works.
The basic gist is: According to semver precedence of pre-releases must be determined by string ordering. It would help us if React complied with semver.
That is what I mean with "there's no ordering". Given two Canary versions, there's no right precedence which version should be chosen. The "rc", "canary", "experimental" etc in these version strings are only helpers to quickly identify what release you're working with.
They do not work by design like rc.0
or canary.0
. If they are, we do release them as such e.g. 19.0.0-rc.0
.
fwiw, 19.0.0-rc.0
is released https://www.npmjs.com/package/react/v/19.0.0-rc.0, but it can't be used with caret.
repro:
$ npm i 'react@^19.0.0-rc.0'
$ jq .dependencies.react package.json
"^19.0.0-rc.0"
$ grep "resolved.*react" package-lock.json
"resolved": "https://registry.npmjs.org/react/-/react-19.0.0-rc-fb9a90fa48-20240614.tgz",
Right, I remembered that wrong. It was purely for a nicer display not to allow caret ranges.
This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize it yet. If you have any new additional information, please include it with your comment!
Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please create a new issue with up-to-date information. Thank you!
Summary
The two latest pre-releases are:
19.0.0-rc-163365a0-20240717
19.0.0-rc-01172397-20240716
According to semver 2 pre-release versions are supposed to be ordered by dot-separated string ordering:
https://semver.org/
The easiest fix would be to reverse the hash- and date-string in the pre-release versions to this:
19.0.0-rc-20240717-163365a0
19.0.0-rc-20240716-01172397
This would help us since some of our toolings rely on this ordering to determine the latest version.