-
Notifications
You must be signed in to change notification settings - Fork 24.8k
Update version number in repo for ecosystem compatibility #5556
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
Conversation
By analyzing the blame information on this pull request, we identified @ide, @cpojer and @tadeuzagallo to be potential reviewers. |
cc @brentvatne |
Have to think about this more, but as a funny aside: http://tenver.org/ |
@corbt updated the pull request. |
(the github bot keeps saying that I've updated PRs that I haven't touched, weird). |
@corbt updated the pull request. |
1 similar comment
@corbt updated the pull request. |
Ping @brentvatne, @ide. Looks good to me. |
Logically this makes sense. We want a version number that is always bigger than anything released so far. |
@facebook-github-bot shipit |
I'll merge this soon, there's a product team stabilizing their code today and not sure this could break anything (seems very unlikely but better to be safe). |
@facebook-github-bot shipit |
Thanks for importing. If you are an FB employee go to Phabricator to review. |
Summary:In facebook#5241 ide updated the version number to be a fake one so that people wouldn't send in PRs just bumping the version. Unfortunately, this leads to compatibility issues when developing against `master` with 3rd-party components that declare React Native as a `peerDependency`. For example, I'm using [react-native-orientation](https://github.com/yamill/react-native-orientation) which has a peerDependency of `"react-native": ">=0.5"`. I see a few ways to deal with this: 1. Only develop against the releases on npm, not git snapshots. 2. Ask ecosystem projects to not include a minimum version of `react-native` in their peerDependencies. 3. Track the RN release numbers in the git repository (eg it would be 0.19 right now). 4. Make the release number on master huge (1000 in this PR) so it's obviously a fake number but will still comply with >= checks. I don't think option 2 is good because it's reasonable for a package author to want to specify a minimum R Closes facebook#5556 Differential Revision: D3110274 fb-gh-sync-id: 8638157d44ee99945337fbf585936b50699f0341 fbshipit-source-id: 8638157d44ee99945337fbf585936b50699f0341
In #5241 @ide updated the version number to be a fake one so that people wouldn't send in PRs just bumping the version.
Unfortunately, this leads to compatibility issues when developing against
master
with 3rd-party components that declare React Native as apeerDependency
. For example, I'm using react-native-orientation which has a peerDependency of"react-native": ">=0.5"
.I see a few ways to deal with this:
react-native
in their peerDependencies.I don't think option 2 is good because it's reasonable for a package author to want to specify a minimum RN version. Option 3 would be fine, although it would take manual effort to keep the version in sync. Option 4 (this PR) is my favorite because it's obvious that the version number is fake, but it maintains ecosystem compatibility.