This page describes how releases of React's individual components are handled. As such, this information mostly applies to React's component maintainers instead of their users (consumers).

We're putting this information out here in order to maintain a transparent process and achieve consistent results.

React used to consist of a core repository containing all evented core components. These components were also exported via a subtree split script into individual read-only repositories. This approach worked out good at the start but soon after turned out to be hard to maintain.

Nowadays, each component lives in its own, individual repository. This also means each components has its own code base, maintainers, PRs, issues, tags and ultimately release cycle.

This applies when tagging a new release.

• make sure CHANGELOG.md is complete
• set CHANGELOG.md release date in stone
• $ git tag -a (annotated git tag)
• $ git push
• Copy-paste the section from the CHANGELOG.md to the repositories' releases page (GitHub feature)

This applies when creating a new component.

• Create GitHub repository in the reactphp organization (create repository "reactphp/foo")
• Create new team with the same name as the component (create new team named "foo")
• Assign push access for team to Github repository (team "foo" can push to "reactphp/foo")
• Add individual maintainers to team (add user "bar" to team "foo")
• Set up services:
  • Packagist
  • Travis CI
  • GitHub IRC hook
• Check the following files:
  • composer.json
  • phpunit.xml
  • .travis.yml
  • LICENSE
  • README.md
  • CHANGELOG.md