[0.26] Commits to cherry-pick into stable release

[grabbou]

• [website] Show simulator also for cross-platform components: [docs] Display platform-specific examples #7406 (02af7b5), we'll need a followup to show both iOS and Android (will be done later separately)
• Picker is broken on Android with a React bugfix: Batch event handling in React Native react#6572 (React dependency updated in 9be37ca). Fix in 0cd2904.
• Update "This shouldn't be possible. Congratulations." message: 1c31aea

[janicduplessis]

Keyboard events are not fireing e72163f (see #7460)

[bestander]

Breaking change for IOS: #7566.
Need react-native upgrade script that will update xcode project

[bestander]

Breaking change for IOS: #7559

[joenoon]

#7518 seems important before 0.26 stable is released. Otherwise everyone is going to have yellowboxes

[grabbou]

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

[ide]

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

[sophiebits]

@zpao

[zpao]

There are a few more things that will go into React 15.1 final… This should be fun.

[ide]

@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 react@15.0.3 latest to hide the newly published version. Should make your life easier and you can then publish 15.1.1 at your leisure.

[zpao]

@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?

• Do we need to publish a non-alpha version for RN 0.26 final? Looks like no based on package.json
• Do we really need to publish a non-alpha version for RN release candidate?
• 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.

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

[ide]

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.

[ide]

@zpao as a concrete proposal, I'd like for RN@0.27-rc 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.

[zpao]

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

[ide]

Totally doable and publishing new RCs is straightforward for RN -- we tag a commit and push it to GitHub and CI does the rest.