We release react-native-windows in lock-step with facebook/react-native. I.e., for every release of react-native, we create a release of react-native-windows with a matching major and minor version.
...
[email protected].* -> [email protected].*
[email protected].* -> [email protected].*
...
This makes the CLI experience for react-native-windows significantly easier to manage, as we can automate the process of installing a compatible version of react-native-windows to an existing react-native project. It also keeps our compatibility matrix small; we don't need to test every version of react-native-windows against versions of react-native, only those with matching major and minor versions. The philosophy is that if something is added in a later version that is needed by users of an older version of react-native-windows, we can always cherry-pick that change into an older version, or users can upgrade.
With that in mind, here is the process for publishing a new release of react-native-windows.
The facebook/react-native project publishes a release candidate from their master branch around the same time they publish a stable version, currently on a monthly cadence.
After a new release candidate is cut, upgrade the react and react-native dependencies. Be sure to check which version of react is currently being used by in the react-native package.json, as we keep this peer dependency aligned as well.
npm i --save react-native@<major>.<minor>.<build>-rc.<id>
npm i --save react@<version>
It may also make sense to look for other NPM dependencies that can be upgraded at this time, especially those that are shared with react-native.
Make sure you also update the react-native-windows version in package.json to align with the react-native version you've upgraded to. We use the same -rc.* convention for release candidates. TODO: We should introduce a script like bump-oss-version.js.
Before moving on to the next step, you'll want to test the package upgrades on the Playground app. The Playground app is a very low bar for testing, as it only uses basic react-native components. However, it will catch the majority of breaking changes to the react-native-windows bridge, which typically include props that have been changes or removed for common components like View and Text, changes to the batched bridge protocol, and new core components and modules that have been added upstream, but have not been added for react-native-windows.
The same example apps from react-native are also available for react-native-windows, including the UIExplorer.
We maintain a fork of the Examples folder from react-native as a submodule of react-native-windows. The fork uses git filter-branch to produce a branch of react-native that includes only the content of the Examples folder. We then merge all the changes specific to react-native-windows with that filtered branch.
# Be sure that you have all submodules initialized and up-to-date for react-native-windows.
cd Examples
# If you don't already have facebook/react-native set up as a Git remote...
git remote add facebook [email protected]:facebook/react-native
# Fetch the latest from facebook
git fetch facebook
# Create a new branch to run the `filter-branch` command only
git checkout -b fbmaster facebook/master
# Filter the react-native master branch for Examples only, this will take some time
# You may have to use `-f` if you've previously run a `filter-branch` command
git filter-branch --prune-empty --subdirectory-filter Examples fbmaster
# Fetch the latest from ReactWindows/react-native-windows
git fetch origin
# Create a new staging branch to perform a merge onto the react-native-windows `examples` branch
git checkout -b staging examples
# Merge the latest from react-native Examples and resolve any merge conflicts
git merge fbmaster
# Fast-forward the `examples` branch from the `staging` branch
# Before doing this, it's probably a good idea to test that the examples are working by running them
# If anything has broken (it's common), fix it
git checkout examples
git merge staging
# Push (or PR) your changes to react-native-windows
git push origin examples
# Cleanup your staging branches
git branch -D fbmaster
git branch -D stagingWe typically do ad hoc testing of core components using the UIExplorer. After upgrading to the latest release candidate of react-native and getting the latest changes to the react-native Examples, you should be able to run the UIExplorer on react-native-windows. After the app launches, be sure to open each module and component section in the app, and test out all the functionality. More than 50% of the time, nothing has broken since the last release. However, changes to props, new APIs being tested in the UIExplorer, or changes to component base classes are common reasons why the UIExplorer can break.
After fixing all the bugs with the UIExplorer, you're ready to share your awesome work with the world!
Create a new branch named with the following convention: <major>.<minor>-stable. Using version 0.40 as an example:
git checkout -b 0.40-stable
git tag v0.40.0-rc.0
git push origin 0.40-stable --tags
Assuming you have authorization to publish a new version of react-native-windows to NPM, this is the easy part. From the release branch you just created, run:
npm publish
We work off the latest release candidate of react-native on our master branch of react-native-windows, so now is a good time to submit a PR of these changes against the master branch.
Coming soon. TODO: We need a process around this like react-native.
Coming soon.
Coming soon.