Intro
This discussion was born in the RN core team, but since the discussion was fairly recent and involves a really small group of devs I decided it was better to use this to move the conversation forward (since it impacts all OSS and allows to clarify how the process works).
The Gist of it
React Native as an Open Source project has many peculiarities, among which the fact that the release cycle for open source is unrelated to the internal FB usage of the library.
For this reason, the release cycle has always been decided informally by members of the core, in particular (from my understanding) @grabbou and a few other devs over time.
The timeframe between a release and the next one used to be by-weekly up to a change in late 2016, when it become monthly. Lately with the introduction of some massive changes (ex. Babel 7) the last two versions 0.56 and (currently being released) 0.57 have lagged a bit behind to this monthly cycle.
This was caused because, of course, priority is given to make sure that the release pass some basic manual testing, and until we are able to generate the RNTester
project and the RNTestProject
we don't proceed to release.
Why standardise
The reasoning behind creating a more "formal/structured" list of steps for a release will allow the community at large to know at any given point why and how the next version is in a certain state, and avoid misscommunication/misunderstanding among the people handling the different pieces of a release. (so, basically, to improve the overall reliability of the process)
A release is, currently, composed of a few different steps, which I list here in the order they are usually (but not necessarely) done:
- a branch with the new version is created, ex
v0.XX-stable
- the branch is tested and a commit to set the right semver is done (example). This commit is then tagged with an
v0.XX-rcXX
version so that the CI can npm publish it. This way we make it easily available for the community to test before doing the "proper" first release. Subsequent RCs can follow if some big bugs are found and fixed.
- after some time (2+ weeks) a first
v0.XX.0
tag is created and the first "official" release for that version is avaiable to everyone. This timewindow is related to how buggy or easy to upgrade to the new version is.
- once
v0.XX.0
has been out for 1/2 weeks the v0.XX+1-stable
branch is created and the cycle starts all over again
A few extra notes:
- At any point between the
v0.XX-rc0
and the first v0.XX+1-rc0
tags, on the v0.XX-stable
branch cherry picks from the "non-stopping" master branch can happen to get some extra fixes or similar.
- a changelog must be written/created (more or less) by the time
v0.XX.0
lands. This is currently mostly handled by @turnrye
- the documentation must be updated to default to
v0.XX
by the time v0.XX.0
lands. This means that can be bumped even during the RC phase. This step is also necessary to keep the PRs to the doc "clean" in terms of knowing which commits of master need to wait for v0.XX+1
to be merged. (this is mostly handled by @hramos and @charpeni)
- we currently use the issue section of the dedicated repo
react-native-releases
to try and keep everyone up to date with the status of each release.
Discussion points
Given that:
- master keeps moving forward at a crazy fast pace
- we want to "ensure" (or at least try) that each new release "works"
- React Native is still not in 1.x semver (meaning, things can and will change! Check the Fabric issue for more details)
There are a few things to consider and discuss:
a) in what order should things happen?
Example, I think that we should not bump docs until the first RC version is released, and we should have the changelog ready for when .0 is out.
b) does it make sense to aim to a monthly release cycle?
We want to keep up the pace of master, but since the bus factor to move the release and bugfix is potentially high it may happen that things move slowly. Maybe we should consider releasing every X breaking changes or something other non-time related parameter?
c) should we remove the rc phase completely?
This was pointed out to me by @grabbou and @rozele earlier today: since we are not in 1.x it technically would make sense to start right away with a vXX.0 tag. And consider 0 as the "test bench". I am afraid this could backfire since there would not have been as much RC testing as there is currently, but again, we are not 1.x so if we can communicate properly to the community that "hey step into the .0 only if you are ready for the battle or wait for .1 for stable" it should be fine.
What do you think? Let's discuss!