Bonjour @conorsch & @redshiftzero,
The release of 0.4 in July went like this, more or less:
- Feature freeze, fixing and testing
- A few days later, the release/0.4 branch is created
- During a few days bug fix required for the release are merged in release/0.4 and the rest of the commits go to the develop branch
- The release is published based on the release/0.4 branch
- A few days later the release/0.4 branch is merged into develop and master via two different pull requests
In retrospect it went very well and the reason for publishing 0.4.1 and 0.4.2 shortly after were unrelated to the release process. It however introduces some friction and delays that we could get rid of.
- When feature freeze is declared, no pull request can be merged until the release branch release/0.4.3 is created, only bug fixes can be merged into develop
- Bug fixes committed to the release branch release/0.4.3 are not available in the develop branch until after the release
- When committing pull requests in develop during the preparation of the release, one has to be careful not to introduce changes that would create problematic conflicts when merging release/0.4.3 back into the develop branch
The SecureDrop release cycle is short and IMHO this optimization is worth thinking about. I propose the process is modified slightly:
- The release/0.4.3 branch is created immediately, i.e. Tuesday 5th, date of the feature freeze.
- The release/0.4.3 branch is merged back into develop daily.
- The release/0.4.3 branch is merged into master via a pull request proposed the same day as the publication of the release / tagging.
The downside is that merging back into develop is a daily burden during the release. But it also means that conflicts are resolved as we go instead of at the end of the release process with a larger, more stressful and more complicated merge.
What do you think ?