Skip to content

Conversation

corbt
Copy link
Contributor

@corbt corbt commented Jan 26, 2016

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 a peerDependency. 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:

  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 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.

@facebook-github-bot
Copy link
Contributor

By analyzing the blame information on this pull request, we identified @ide, @cpojer and @tadeuzagallo to be potential reviewers.

@facebook-github-bot facebook-github-bot added GH Review: review-needed CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. labels Jan 26, 2016
@satya164
Copy link
Contributor

@satya164
Copy link
Contributor

cc @brentvatne

@brentvatne
Copy link
Collaborator

Have to think about this more, but as a funny aside: http://tenver.org/

@facebook-github-bot
Copy link
Contributor

@corbt updated the pull request.

@corbt
Copy link
Contributor Author

corbt commented Feb 12, 2016

(the github bot keeps saying that I've updated PRs that I haven't touched, weird).

@corbt corbt force-pushed the package-version branch from ee48a01 to ea0558e Compare March 5, 2016 16:25
@facebook-github-bot
Copy link
Contributor

@corbt updated the pull request.

1 similar comment
@facebook-github-bot
Copy link
Contributor

@corbt updated the pull request.

@mkonicek
Copy link
Contributor

Ping @brentvatne, @ide.

Looks good to me.

@ide
Copy link
Contributor

ide commented Mar 20, 2016

Logically this makes sense. We want a version number that is always bigger than anything released so far.

@ide
Copy link
Contributor

ide commented Mar 20, 2016

@facebook-github-bot shipit

@mkonicek
Copy link
Contributor

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).

@corbt
Copy link
Contributor Author

corbt commented Mar 29, 2016

@facebook-github-bot shipit

@facebook-github-bot
Copy link
Contributor

Thanks for importing. If you are an FB employee go to Phabricator to review.

@ghost ghost closed this in bbeeaa1 Mar 29, 2016
zebulgar pushed a commit to nightingale/react-native that referenced this pull request Jun 18, 2016
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
This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants