Stay up-to-date with the release activities of React Native by watching for status reports. Follow along as the release notes are prepared and review the overall changelog.
Progress towards release is tracked in issues. Look for these issues labelled release status. Soon a standardized format for the update will be published; please be patient while this settles.
Note that these issues are locked to keep conversation focused strictly on the status. Questions about the release should be directed to the React Native repository or other communications channels.
The changelog in this repository is a community-provided effort to provide a helpful and informative summary of React Native's rapidly changing codebase. The format is based on Keep a Changelog and emojii use is roughly based on gitmoji recommendations.
In order to allow additional research, the commits that relate to a change are listed. The revisions listed typically are the merge commits, so as to match the code that a user may find in their own copy. Authors are attributed to encourage recognizing the contributors for supporting React Native.
In order to generate the Changelog, we use a script that, given a base version and a target version, checks all the commits between the two versions and parses release notes and authors in the commit message - and then prints it in the terminal for easy/copy paste.
To use it first off git clone the repo, then yarn and finally you can use it like in the following example: ./changelog-generator.js -b v0.57.5 -c v0.57.6.
React Native follows a monthly release cycle. Once a pull request is merged to the core react-native repo, it may take one to two months for the changes to make it to a stable React Native release.
To determine whether a fix or feature is present in a given release, you will need the commit hash where the fix or feature was added to the master branch of the core react-native repo. If you know the PR, you can look for the comment from @facebook-github-bot that says 'closed this in <COMMIT_HASH>'.
Once you have the commit hash, navigate to https://github.com/facebook/react-native/commit/<COMMIT_HASH>. Look closely at the commit message, underneath which you will find a list of tags associated with the commit. These tags will tell you which releases contains this commit. For example, commit 5e80d95e034259af8c41b50756a623756cc81a77 has the following tags as of this writing: v0.55.0-rc.0 v0.54.2 v0.54.1 v0.54.0 v0.54.0-rc.4 v0.54.0-rc.3 v0.54.0-rc.2 v0.54.0-rc.0 latest. These tags tell us that the commit first made it into the 0.54 release candidate, eventually landing in the 0.54 stable release. It is also present, as you'd expect, in the 0.55 release candidate (and should make it to 0.55 stable, and so on).
If the commit is only present in master (i.e. has no tags), then the commit has yet to be picked up by a release. You can expect it to be included in the next release candidate that is cut at the beginning of the next month.
From time to time, backporting a change to an existing release (including candidates) may be needed. Examples include security issues or critical regressions. If you believe a pull request on react-native is a candidate for backporting, please mention it in the version associated backport request issue.
Please note that, if the change hasn't landed on react-native's master, it can't be cherry picked to a release tag yet.