Lightweight release branch suggestion
Brian Smith <br...@...>
Problem: When we get close to a release, we currently "freeze" the master branch of the Conduit repo until the release is completed. Only high-priority and low-risk changes are accepted in the frozen state. No other PRs can get merged. Sometimes the tree can be frozen for longer than we expected and sometimes it isn't clear even if the tree is frozen.
Suggestions for a basic solution.
(This is based on partially on my experience with a similar system at Mozilla, working on Firefox.)
* Developers: If you are working on a major change, especially if the change might benefit from being done in multiple PRs and/or is high risk, considering adding a build-time or runtime option to control whether your change is active. This will often not be practical, but it often is practical. Then, at release time, reverting your change can be done on the release branch by simply changing the default setting of that flag. If you add such a flag controlling your feature, then make sure that is clear in the PR, and especially in the merge commit message when the PR is merged.
* Developers: If you are working on a code change that can't land until the current release is cut, and can't be disabled with a feature flag, make that clear in the GitHub issue and/or PR, and also ping the release manager.
* Release manager: When we get "close" (TBD) to the release date, ping everybody assigned issues/PRs targeting the release to get their changes in ASAP or provide an ETA. Once "almost all" (TBD) of the changes for the release are in, come to an agreement with Oliver + the people assigned the remaining outstanding issues about how to deal with creating a release branch. This should be done late in the process to minimize the mumber of changes that need to be merged onto both branches, but before too much work is blocked on the release.
* Release manager: Create the release branch and email conduit-dev a link to the release branch and indicate what changes are still pending for that branch. If we've decided to disable a previously-landed change on the release branch, then disable that feature on the release branch. Do so by flipping the flag that controls it, or by reverting a commit that added it, or creating a new commit to effectively disable the feature. (The release manager probably shouldn't be writing such commits; they should work with the developer of the change to get the commit written.) Such changes, of course. should be done in the form of PRs that are reviewed by the relevant people, based on the release branch (not master).
* Developers: Everybody keeps landing changes on the master branch. If a change is also intended for the release, then *AFTER* merging the change to the master branch, create a new PR that lands the same change into the release branch. Backporting the change to the release branch may involve significant effort; whenever possible, avoid that effort by getting your changes merged ahead of the branch point.
* There is no merging between the release branches and the master branch, ever.
* An initial release verification walkthrough happens on the release branch sometime soon after the branch is created. Another walkthrough after all changes are done is probably necessary too.
* If we need to create a point release to a feature, we'll land the fix (if still relevant) to the master branch, and then backport it to the release branch. AFAICT we don't ever need to create sub-branches of the release branch for point releases.
Phil Calçado <ph...@...>
toggle quoted messageShow quoted text
Thanks for putting proposal this together, Brian!
The way I understand your proposal, you are suggesting that:
1. At the beginning of the release cycle, everyone is developing towards master as usual.
2. At some tbd point, the person wearing the release manager hat for this particular release will create a branch for it.
3. From this point on, developers should post their changes to master and, once they get accepted into master, make a PR to promote the code change to the release branch.
Step #3 might be a little convoluted as it is not unexpected that master and release will diverge at some later point in the release cycle. To deal with any impedance, developers need to backport their code so that it works with the release as well. Whereas just plain backporting is an option, we should try to use feature toggles or, probably better, branch by abstraction to make sure that we can enable/disable features that aren't ready for the release.
Basically, we get to this diagram from Paul Hammant's article linked above:
Is my interpretation correct?
If so, I +1 the idea. I have applied similar strategies in driving teams towards Continuous Delivery, and as long as we don't have an explosion of branches I think it could work well.
On Mon, Mar 19, 2018 at 9:09 PM, Brian Smith <br...@...> wrote: