Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Upgrade React Native peer dependency to 0.54. #2115
Does any other open PR do the same thing?
What issue is this PR fixing?
This library has some regressions when used with React Native 0.54 - we were using the project with 0.54, and were facing #2100 for example.
Further, I was trying set up some iOS integration tests using the built-in RCTTest library, and I was not able to set it up using RN 0.51. (It works fine on 0.54)
It would be great if we could upgrade the RN version so that this work can continue. I feel that native<->JS integration tests (& possibly also native snapshot tests) will make it much easier to maintain backwards compatibility & avoid serious regressions like the current one we're facing.
How did you test this PR?
I have not tested this change with Android, as I currently don't have Android Studio installed. I have updated the Android manifest file as per rn-diff, so in theory this should build properly. I would appreciate any help with that - a simple
Changes to Bundler
This PR also makes the following changes to how Ruby gems are installed:
referenced this pull request
Mar 20, 2018
The README suggests that this repo will only support the latest version of React Native- though I understand that doesn't mean pulling the plug on everyone else is the right thing to do. Perhaps it could get bundled with a new minor release version, where those on RN < 0.54 can stick to 0.20.x and you can publish any other changes as patch versions on 0.20.
Speaking of semver, when will the first major version be? Do you have any plans for a 1.0.0 release? I think the lib is ready for it but I don't know if the collaborators have any further plans before then.
If you were to release version 1.0.0 as the first major version, you could easily just say that version 1.X.X required RN >= 0.54 and have 0.X.X remain compatible with RN < 0.54. You can still publish more minor and patch versions to 0.X.X as fixes, optimizations, etc, and just go forward with 1.X.X for new features, etc.... This is what I would do.