Keyboard events are not fireing e72163f (see #7460)
Breaking change for IOS: https://github.com/facebook/react-native/issues/7566.
Need react-native upgrade script that will update xcode project
Breaking change for IOS: https://github.com/facebook/react-native/issues/7559
https://github.com/facebook/react-native/pull/7518 seems important before 0.26 stable is released. Otherwise everyone is going to have yellowboxes
@joenoon I was aiming for the release tomorrow around midday (14 days from the RC cut) along with the 0.27-rc. Hopefully we can get this merged to master before that happens, otherwise we will either have to delay it or ship 0.26.1.
React needs to publish 15.1.0 to npm as well for 0.27-rc since RN master currently depends on the alpha and npm can't handle the heat prerelease versions. cc @spicyj @sebmarkbage
@zpao
There are a few more things that will go into React 15.1 final… This should be fun.
@zpao one idea is to publish what you have as 15.1.0 or 15.0.4 (doesn't really matter -- only RN 0.27 users are going to use it) and set npm dist-tag add [email protected] latest to hide the newly published version. Should make your life easier and you can then publish 15.1.1 at your leisure.
@ide Like I said in the other thread, doing releases like that really isn't ideal and makes several things unclear. It only makes things "easier" in that we sweep the mess under the rug and pretend it's not there. We also burn 15.1 if there are other things that should go in a minor release (and there are a few, which I would like to release together)
Can we establish the requirements from React here?
package.jsonI think we need to work more closely moving forward. We're off to a bit of rocky start and I'm definitely at fault here for not aggressively cherry-picking & shipping more alphas, and not being aware of the exact timing of RN releases (I thought we had several more days before we had to make a final release). There's more to work out on the React end of this release process but hopefully we can.
It only makes things "easier" in that we sweep the mess under the rug and pretend it's not there
Yes, but RN publishes every two weeks and we don't support old versions so the mess under the rug doesn't matter after two weeks.
Do we need to publish a non-alpha version for RN 0.26 final?
RN 0.26 is fine because it doesn't depend on the alpha.
Do we really need to publish a non-alpha version for RN release candidate?
We don't need, but want, in the sense that we encourage people to install RCs and generally aim for the RCs to work end-to-end. Anyone who depends on react-native plus another module that lists react as a peerDep (ex: react-redux) will get warnings from npm install and hard errors from npm shrinkwrap.
We could go ahead and publish 0.27-rc as-is (with the prerelease dep) if we update the react dep to a non-prerelease version within a few days after. We'll mention the prerelease/peerDep issue as a Known Problem in the release notes.
If we really need a non-alpha version publish, How bad would it be to throw a bunch more into 15.1 tonight? I don't actually want to do that and ship it as a blessed version but #yolo.
That's the riskiest solution for React and React Native -- seems better to ignore semver in a way that doesn't really matter and publish 15.1.0-alpha.1 as 15.1.0 and then later deprecate it and publish 15.1.1 with all the features you want to land.
@zpao as a concrete proposal, I'd like for [email protected] to depend on a non-prerelease version of React by Monday so people have more time to test the RC with that latest version of React. If you believe 15.1.0 is almost ready to ship and will be ready by Monday, let's aim for that. If not and 15.1.0 needs more time to bake, then I lean towards publishing 15.1.0-alpha.1 as 15.1.0 without the latest dist-tag, and then publishing 15.1.1 at a later time.
In either case, people who depend on react@^15.0.0 won't get 15.1.0 (only react-native users will) and when 15.1.1 is published, both react and react-native users will get 15.1.1 -> this seems good and not so disruptive.
@ide 👍 If we ship an alpha.2 tonight/tomorrow, can we get that into RC for testing? If that's before the cut can we do another RN RC? I guess you'd be doing another come Monday with this proposal so I assume doable but perhaps not ideal.
Totally doable and publishing new RCs is straightforward for RN -- we tag a commit and push it to GitHub and CI does the rest.
0.26 is ready to go to npm. I am working on the upgrade script and planning to land it in the evening. Once that's done, we are ready to proceed.
@ide re 0.27 - shall we just publish it today as is and wait for the React update to publish rc2?
FYI everything has been cherry picked.
and not being aware of the exact timing of RN releases (I thought we had several more days before we had to make a final release).
@zpao The React Native release and branch cut is on Monday every two weeks: https://github.com/facebook/react-native/blob/master/Releases.md
I am going to close this one as the stable release has just been sent to the Circle. We can continue our discussion here -> https://github.com/facebook/react-native/issues/7616
👍 Thanks for driving the releases @grabbou!
If we ship an alpha.2 tonight/tomorrow, can we get that into RC for testing?
@zpao Yes definitely. Can you release React so we can cut the 0.27 rc branch please?
@mkonicek please see the discussion with @ide above. The plan as of last night is to leave on the alpha right now and ship a non-alpha by Monday.
0e997c6eabae79c99823459b39b885547f824955 - fixes a bug where NavigationPropTypes.SceneRenderer was a plain object
@mkonicek @ide shall we cut 0.27 now then or wait till Monday?
@grabbou Let's cut 0.27-rc now and then publish 0.27-rc.2 when React 15.1.0 is published (which may be on Monday or sooner).
I am thinking we need to send the 0.26.1 out with the https://github.com/facebook/react-native/issues/7648#issuecomment-220669053. We can also safely remove my last upgrade commit, it's no longer needed.
@ide @grabbou @mkonicek React 15.1.0 just went out so you're free to go. Only has a couple tiny fixes on top of alpha.1 so should be quite safe
@zpao thanks!
Most helpful comment
Keyboard events are not fireing e72163f (see #7460)