release, documentation, tools: Expand patch management support to the previous two minor versions

[jpbetz]

As part of a larger effort to align the supported etcd versions with versions of etcd kubernetes supports, we propose extending the officially supported etcd versions from one previous minor release version to two.

Background / Rationale:

Current state:

Aspirational State:

(Note that kubernetes will always lag by at least 1 minor etcd release version due to the quarterly release cadence of both projects)

How can we make progress toward the aspirational state? For kubernetes supported versions, move trailing edge forward with a deprecation policy of older etcd versions that is enforced by kube-apiserver, and move the leading edge forward with an adoption policy and schedule regular etcd upgrades supported with automated test and upgrade tooling. Establish better alignment with the actively maintained etcd version window by introducing patch management of etcd versions in use by kubernetes.

The focus here is alignment with the actively maintained etcd version window.

Resourcing:

Supporting an additional release branch takes real engineering effort beyond what we can reasonably ask CoreOS to be soley responsible for. For this to work, the community needs to pitch in and be involved.

I volunteer to take on the 3.1 and 3.2 release branch patch management duties. As qualification I offer my patch manager experience from kubernetes 1.8, and my etcd contributions, for review.

For 3.3+ we will identify patch managers from the community. As an assurance that this position will not go unmanned in the foreseeable future, @jpbetz, @cheftako and @mml are already available, and we expect other engineers to be available in the near future.

Tooling:

cherrypick script: This PR ports the kubernetes cherrypick script over to etcd to help automate the cherrypick process. Is this needed? Previous etcd has cherrypicked commits without introducing a PR to track them. The potential benefit of the PR is to facilitate automated testing. But if this adds too much additional process to etcd patch release management, I can remove the tool from this PR. Feedback welcome. Example usage to cherrypick PR 12345 to the release 3.2 branch:

hack/patch/cherrypick.sh origin/release-3.2 12345

needs-backport labels: With only one supported release branch needs-backport could always be interpreted to mean that a PR merged to master needed to be cherrypicked to the previous release. With multiple supported releases, we need to allow a backport request to specify which releases a PR needs to be backported to. We will add needs-backport-<major>.<minor> labels to facilitate this.

semaphore support for 3.1: Semaphore support was backported to 3.2 by 2f74456 . We'll do the same for 3.1, see #8807.

[gyuho]

Q. Do you have example commands to use hack/patch/cherrypick.sh?

LGTM. Thanks!

/cc @xiang90

[jpbetz]

@gyuho The help output shows a couple examples, To cherrypick PR 12345 to the 3.2 branch, I would typically do something like:

hack/patch/cherrypick.sh origin/release-3.2 12345

This will create a PR, which can then be tested by travisCI and semaphore.

It's also possible to cherry pick multiple PRs at once:

hack/patch/cherrypick.sh origin/release-3.2 12345 12346 ...

[gyuho]

c.f. #7308

[xiang90]

I am on board with extending the support to two minor versions for two reasons:

1. etcd itself is maturing enough so that two minor releases wont diverge too much except new features
2. we get @jpbetz and others from google committed to help

[xiang90]

@jpbetz Can you provide a simple readme file for the cherrypick tool? I think this PR is ready to merge.

[jpbetz]

@xiang90 Added.

[xiang90]

lgtm