Update the release strategy docs

Review Request #3890 — Created May 14, 2016 and submitted

jsirois, lahosken, mateor, molsen, zundel

There's a lot in here, but the key change is to try to weave pre releases into the strategy consistently.

  • Wove pre releases into the strategy doc, as differentiated from stable releases
  • Clarified release manager responsibilities
  • Renamed to Release Strategy
  • Linked back and forth between Release Process and Release Strategy, and explained the difference
  • Clustered the release-related links on the Developer Center page

rendered: http://pantsbuild.github.io/staging/stuhood-release-strategy/dev.html


  • 0
  • 0
  • 3
  • 1
  • 4
Description From Last Updated
  2. src/docs/release_strategy.md (Diff revision 1)

    I dunno what an even week is. Maybe that's OK; maybe I'm supposed to have learned this by having paid attention to the release process for a while... which would be a darned good idea before carrying out these steps, yep. But IF you're hoping that this doc will tell me everything I need to know to do a release: I dunno what an even week is.

    1. The even week might be better described as "If the prior release manager started an RC vote".  That is certainly the awkward part of the current arrangement of release managers being scheduled weekly and stable releases being scheduled over minimum 2-week spans.
      This doc is great to have, so LGTM, but I do think this last bit is revealing.  An stable release can hand off between 4 releasers if there are enough RCs. I, for one, am not looking forward to the mental juggling!
  3. src/docs/release_strategy.md (Diff revision 1)

    nit: commas at different whaddyacallem precedence levels are confusing

    created (perhaps because it is an "odd" week or because the release manager decided there was insufficient change in master to justify the stable vetting process) the release manager

  4. src/docs/release_strategy.md (Diff revision 1)

    nittiest nit: I bet this example's "would <verb>" oughta become "<verb>ed"

  1. Ship It!
  2. src/docs/release_strategy.md (Diff revision 1)

    I think we need to say something about how patches get into the stable release. Currently we have this spreadsheet setup. I don't know if that's sustainable - working out merge conflicts between master and the stable branch shouldn't be the release manager's job.

    I would like to say that the person creating the patch creates an RB for it and merges it into the stable branch.

    1. re: @mateo as well: I guess I'm fine with that.

      Any idea how to suggest that people request a release from a particular stable branch? Mail to pants-devel@?

    2. I think there is more work to do to find the optimal workflow for backports, but I don't think that email is the right way. If possible, I'd like to leave the Pants Backport spreadsheet in place for the purposes of this review and the next stable releases, and we can treat improving the backports workflow as a separate issue. Kosher?

  1. Thanks for the docs, Stu!

    I think I agree with Eric that commits landing on LTS branches should be separate from release. For a release manager, the qualification for doing a patch release of a LTS could be that authors have landed patches on that tag. A check could conceivably be added to the release scripts.

  2. src/docs/release.md (Diff revision 1)

    For patch fixes for stable releases this could be a pretty large extra burden. Slack conversation seems to be going towards monthly releases. After a year that could mean you would have to do the normal release plus 12 patch releases.

    I think doing patch releses may make more sense to be handled separately.

    1. After a year that could mean you would have to do the normal release plus 12 patch releases.

      I think the consensus is very much that we won't have lots of live stable branches at once.

      The primary question now though is whether to accomplish that by 1) creating stable branches less frequently, 2) doing patch releases of stable branches on demand, and allowing more of them to exist. Will poll the mailing list about it.

  3. src/docs/release_strategy.md (Diff revision 1)

    (if necessary) if this is a regular pre-release my understanding is we would release out of master and add a tag 1.x.y-preN

    1. That's described pretty clearly below (I hope.)

  4. src/docs/release_strategy.md (Diff revision 1)

    I think in the case of major releases, this should not be up to the release manager and should be based on consensus.

    1. Agreed. Will update.

  5. src/docs/release_strategy.md (Diff revision 1)

    I think bugs should always be backported to releases we are still supporting and performance fixes when reasonable.

    1. Will clarify that this includes fixes and small features.

      But I don't think bugs should "always" be backported... part of the stability in the branch comes from backporting only enough code to satisfy users of the branch. If you agree, I can add that as a comment.

  1. Ship It!
  1. Ship It!
Review request changed

Status: Closed (submitted)

Change Summary:

Merged as 171eef294d9f22c066baadf3e3953bed9d0049df and published to http://www.pantsbuild.org/