We should decide in the next week if we want to do a smaller 0.5.2 release in between 0.5.1 and 0.6 (keeping the current deadline for 0.6 - March 13). The primary reason to consider that is that this important fix https://github.com/freedomofpress/securedrop/pull/2748 was not ready to go for the merge window for 0.5.1 and it’s high priority to get this out to production SecureDrops as soon as possible.
This could be a release done in the regular way, a merge of develop into master - which would necessitate the translations being ready to go with any new changes. As an alternative, for high priority backend bug fixes, I think it might make sense to do a release branched off master in order to minimize burden on translators. We would need to be disciplined about post-release cleanup (in the past a very large diff between develop and master developed that made the release process extremely slow/difficult, see https://github.com/freedomofpress/securedrop/issues/1559 for history on that) in this case.
It would make a lot of sense to maintain stable branches that only get backport commits from develop. This is a release model that is well documented and it would allow for stable releases to be scheduled when required by the severity of the fix. Since all SecureDrop instances are automatically updated, it is relevant despite our current release cycle of six weeks (which is very short).
It could go like this:
- All development happen on develop (like today)
- A stable branch is created every six week (like today) and is named release/0.X (never release/0.X.Y) and the tag v0.X.0 is set for the major release
- If a bug needs fixing …
- … and exists in develop, it is first fixed in develop and the commits are backported (using cherry-pick -x) to the release/0.X branch
- … and is unique to release/0.X, it is fixed in the release/0.X branch
- the tag v0.X.Y+1 is set for the minor stable release
- The packages are built from the most recent tag
The master branch would no longer be needed. Would that work and also address your concerns about a divergence between master & develop ?
1 Like
I think the decision should be about the workflow, not whether to postpone getting that fix (just that fix) to the world. Which workflow you prefer is part personal taste, part ‘what works here.’ @dachary s proposal is one I like, except that I’d do all development on ‘master’ and abandon ‘develop,’ just stating what tastes and colors I prefer, you & team have to actually deal with it and decide.
1 Like