facebook / react

The library for web and native user interfaces.
https://react.dev
MIT License
229.36k stars 46.97k forks source link

Make pre-release version naming align with semver 2 #30415

Closed pgsandstrom closed 2 weeks ago

pgsandstrom commented 3 months ago

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/

Precedence for two pre-release versions with the same major, minor, and patch version MUST be determined by comparing each dot separated identifier from left to right until a difference is found

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.

eps1lon commented 3 months 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

pgsandstrom commented 3 months ago

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.

eps1lon commented 3 months ago

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.

dai-shi commented 3 months ago

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",
eps1lon commented 3 months ago

Right, I remembered that wrong. It was purely for a nicer display not to allow caret ranges.

github-actions[bot] commented 3 weeks ago

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!

github-actions[bot] commented 2 weeks ago

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!