The list of releases with notes can be found at: https://github.com/facebook/react-native/releases
Version | RC release | Stable release |
---|---|---|
0.22.0 | week of Mar 7 | Mar 21 |
0.23.0 | week of Mar 21 | Apr 4 |
0.24.0 | week of Apr 4 | Apr 18 |
0.25.0 | week of Apr 18 | May 2 |
0.26.0 | week of May 2 | May 16 |
0.27.0 | week of May 16 | May 30 |
... | ... | ... |
The following are required for the local test suite to run:
- Mac OS X with Android dev environment set up
- At least 0.2.0 react-native-cli installed globally
Before cutting a release branch, make sure CI systems Travis and Circle are green.
Before executing the following script, make sure you have:
- An Android emulator / Genymotion device running
- No packager running in any of the projects
./scripts/test-manual-e2e.sh
This script bundles a react-native package locally and passes it to the react-native
cli that creates a test project inside /tmp
folder using that version.
After npm install
completes, the script prints a set of manual checks you have to do to ensure the release you are preparing is working as expected on both platforms.
Run:
git checkout -b <version_you_are_releasing>-stable
# e.g. git checkout -b 0.22-stable
node ./scripts/bump-oss-version.js <exact-version_you_are_releasing>
# e.g. node ./scripts/bump-oss-version.js 0.22.0-rc
git push origin <version_you_are_releasing>-stable --tags
# e.g. git push origin 0.22-stable --tags
Circle CI will automatically run the tests and publish to npm with the version you have specified (e.g 0.22.0-rc
) and tag next
meaning that this version will not be installed for users by default.
Go to Circle CI, look for your branch on the left side and look the npm publish step.
Write the release notes, or post in React Native Core Contributors that the RC is ready to find a voluteer. You can also use react-native-release-notes to generate a draft of release notes.
To go through all the commits that went into a release, one way is to use the GitHub compare view:
https://github.com/facebook/react-native/compare/0.21-stable...0.22-stable
Note: This only shows 250 commits, if there are more use git.
When making a list of changes, ignore docs, showcase updates and minor typos.
Sometimes commit messages might be really short / confusing - try rewording them where it makes sense. Below are few examples:
Fix logging reported by RUN_JS_BUNDLE
->Fix systrace logging of RUN_JS_BUNDLE event
Fixes hot code reloading issue
->Fix an edge case in hot module reloading
Before posting the list of changes, consider asking one of contributors for their opinion. Once everything is ready, post the release notes: https://github.com/facebook/react-native/releases
Important: For release candiate releases, make sure to check "This is a pre-release"
Tweet about it! Link to release notes and say "please report issues" and link to the master issue to track bugs you created.
IMPORTANT: Track bug reports from the community during the following two weeks, ping owners to get them fixed
A good way to do this is to create a github issue and post about it so people can report bugs. Examples: #6087, #5201
Only cherry-pick small and non-risky bug fixes. Don't pick new features into the release as this greatly increases the risk of something breaking. The main point of the RC is to let people to use it for two weeks and fix the most serious bugs.
After cherry-picking 1-2 bug fixes, it is a good idea to do a new RC release so that people can test again. Having a few RC releases can also help people bisect in case we cherry-pick a bad commit by mistake.
git checkout 0.version_you_are_releasing-stable
# e.g. git checkout 0.22-stable
git pull origin 0.version_you_are_releasing-stable
# e.g. git pull origin 0.22-stable
# Cherry-pick those commits
git cherry-pick commitHash1
# IMPORTANT: Test everything again (Chrome debugging, Reload JS, Hot Module Reloading)
./scripts/test-manual-e2e.sh
If everything worked:
node ./scripts/bump-oss-version.js <exact_version_you_are_releasing>
# e.g. node ./scripts/bump-oss-version.js 0.22.0-rc1
git push origin version_you_are_releasing-stable --tags
# e.g. git push origin 0.22-stable --tags
Roughly two weeks after the branch cut (see the release schedule above) it's time to promote the last RC to a real release.
Once all bugfixes have been cherry-picked and you're sure the release is solid (example: #6087), do the release:
git checkout 0.version_you_are_releasing-stable
# e.g. git checkout 0.22-stable
git pull origin 0.version_you_are_releasing-stable
# e.g. git pull origin 0.22-stable
# Cherry-pick those commits, if any
git cherry-pick commitHash1
# IMPORTANT: If you cherry-picked any commits, test everything again (Chrome debugging, Reload JS, Hot Module Reloading)
./scripts/test-manual-e2e.sh
If everything worked:
node ./scripts/bump-oss-version.js <exact_version_you_are_releasing>
# e.g. node ./scripts/bump-oss-version.js 0.22.0
git tag -d latest
git push origin :latest
git tag latest
# The latest tag marks when to regenerate the website.
git push origin version_you_are_releasing-stable --tags
# e.g. git push origin 0.22-stable --tags
Once you see the version in the top left corner of the website has been updated: Move the release notes to the tag you've just created. We want single release notes per version, for example if there is v0.22.0-rc and later we release v0.22.0, the release notes should live on v0.22.0: https://github.com/facebook/react-native/tags
For non-RC releases: Uncheck the box "This is a pre-release" and publish the notes.
Tweet about it! :) (example tweet)