Proposal for a new release cycle based on stable branches

Development
1

Bonjour,

For 0.5.2 we chose to merge back to master because that’s what we’ve done for 0.5 and 0.5.1. Moving forward it would be easier and more consistent (as discussed in a separate thread) to create a release/0.X branch from develop for the release and tag the commit to be released with 0.X.0. Instead of abandoning the branch, we keep the branch, in case we need to publish a release with just a few important fixes, like 0.5.2.

The only change required to make that work is that all commits added to the release/0.X branch must be cherry-pick -x from develop. We never fix a bug in the release/0.X branch, we fix it in develop. This will not cause conflicts (or simple ones) during the release/0.X.0 QA because it was recently cut from develop. It will become increasingly difficult as time passes. But since our release cycle is 6 weeks, it won’t get out of hands.

Of course there will always be exceptions, i.e. fixes that do not make sense in develop and that we must add to the release branch. When that happens the commit message is expected to clearly articulate why this commit is unique to the release branch.

Current release cycle

For a major release:

  • branch release/0.X.Y from develop
  • fix bugs in release/0.X.Y
  • merge back fixes from release/0.X.Y to develop daily so all commits in release/0.X.Y are also in develop
  • release from the release/0.X.Y branch
  • merge release/0.X.Y to master

For a bug fix release 0.X.Y+1

  • fix all bugs in develop
  • branch release/0.X.Y from master
  • cherry-pick -x only the commits we need from develop
  • fix bugs discovered in QA in develop and cherry-pick -x them in release/0.X.Y
  • release from the release/0.X.Y branch
  • merge release/0.X.Y to master
  • tag the tip of master as 0.X.Y

Proposed release cycle

A major release is 0.X.0 instead of 0.X and follows the same steps as bug fixes releases

For a major release:

  • branch release/0.X from develop

For each release 0.X.Y

  • fix bugs in develop and cherry-pick -x them in release/0.X
  • tag the commit of the release as 0.X.Y
  • release from the 0.X.Y tag

What do you think ?

2 Likes
2

Thanks for writing this up @dachary - I think this is a fine approach, let’s try it in the 0.6 release cycle :slight_smile:

1 Like
3

Just to clarify, every release will be 0.X, 0.X+1, 0.X+2 and the patch version is only for bug fixes. If so, I’m on board for this.

4

So are we opening up two PRs now?

One for the fix --> develop + and one for the fix --> this release branch?

5

Yes. In the past what happened is that someone opened a PR in the release branch. And then I opened a PR to merge that back in develop. This whole thing is a cunning way to cut on my work :wink:

In all seriousness this is better because when we merge back to develop, even if it is one commit at a time, we don’t review as carefully and we take a risk. We assume QA in the release is good enough to merge something in develop. Not a big deal because we can always fix things in develop but not a good thing either.

What happened in the past is that we merged back to develop at the very end of the release, after it was published. That was a sizeable number of commits with a good chance of conflict. It routinely took days to make sure we were not doing something wrong. And guess what… we did something wrong a few times. Again, not a catastrophy but … time consuming.

So yes, it is an additional burden on the person fixing the bug. But it also saves time for the person(s) merging back to develop and is less risky. IMHO it saves time globally.

6

Here is an example of a second PR merge back 0.6 into develop 2018-03-01 · Pull Request #3083 · freedomofpress/securedrop · GitHub to merge back to develop. That’s how it was done in the past few months and you can find traces of that in Release SecureDrop 0.5.1 · Issue #2813 · freedomofpress/securedrop · GitHub etc.

7

No objections to the proposal outlined above. It is a bit more work, but we get clear advantages: fewer conflicts, so post-release backports are more straightforward, and additionally develop stays useful since bugfix backporting doesn’t have to wait until after release. :+1: