Skip to content

Instantly share code, notes, and snippets.

@mdlinville

mdlinville/release_1.12.md

Created July 11, 2018 17:38
Show Gist options
  • Save mdlinville/daa4f9285085208127e3fa14c42b81b8 to your computer and use it in GitHub Desktop.
Save mdlinville/daa4f9285085208127e3fa14c42b81b8 to your computer and use it in GitHub Desktop.
Download ZIP
Release process for 1.12
Raw
release_1.12.md

Release meister docs

This is a work in progress and is pending agreement on an integration-branch workflow. You don't need all of that stuff in place to get started, though.

Early steps

  1. Create 1.12 working branch (I propose dev-1.12 instead of release-1.12) locally, based on master. Push it to upstream.
  2. First PR: Update config.toml to show 1.12 as the current version and add the 1.12 entry to the drop-down.
  3. Announce that 1.12 branch is open for new feature docs.
  4. Make a PR against master to edit the PR template to give advice about raising 1.12-related PRs against the 1.12 branch.
  5. Make an on-hold PR between the 1.12 branch and master, titled "Release Kubernetes 1.12 docs" or similar. This PR will always show the current state of the 1.12 branch, allow you to see a preview of the current state of the docs, and allow you to see all the new work that went in since it was branched.

Mid steps

  1. Periodically merge master into 1.12 by raising a PR between the two. (this is the opposite direction from step 5 above).
  2. Periodically merge both master and 1.12 into an integration branch TBD.
  3. Make a query showing all PRs raised against 1.12 and monitor that regularly. You can select all and assign them to the 1.12 milestone. But I found that the query for the base branch was easier to track.
  4. For a given PR, when it has technical sign-off via /lgtm, you almost always need to do a copyedit / rewrite. Get technical sign-off on your copyedit before approving and merging the PR, unless you are absolutely sure you haven't changed any technical meaning. If you can't handle all the copyediting, assign some of these out to other sig-docs members.
  5. Monitor the feature tracking spreadsheet.
  6. Enforce deadlines. Communicate with SIGs via Slack and email lists to keep up to date on status.
  7. Attend the release meetings.

Late steps

  1. Generate reference docs (after code freeze).
  2. For PRs that won't make the release, change their milestone and make sure everyone is clear.

Doing the release

  1. Merge master into 1.12 again if needed (check the on-hold PR for conflicts).
  2. Remove the hold from the on-hold PR when needed and merge into master.
  3. Tag the current state of the integration branch as the final commit for 1.11.
  4. Merge master into the integration branch TBD.
  5. Tag the new integration branch state as the 1.12 release.
  6. Close the 1.12 milestone.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment