Skip to content

Latest commit

 

History

History
296 lines (221 loc) · 11.8 KB

RELEASE-LEADS.md

File metadata and controls

296 lines (221 loc) · 11.8 KB
Raw

Release Leads

For each release cycle, we dedicate a team of two individuals, one from Eventing and one from Serving, to shepherd the release process. Participation is voluntary and based on good faith. We are only expected to participate during our local office hour.

Roster

We seed this rotation with all approvers from all the Serving and Eventing workgroups, excluding productivity. If you are no longer active in Knative, or if you are contributing on personal capacity and do not have time to contribute in the rotation, feel free to send a PR to remove yourself.

Serving roster

This roster is seeded with all approvers from Serving workgroups.

  • dprotaso
  • julz
  • JRBANCEL
  • markusthoemmes
  • mattmoor
  • nak3
  • tcnghia
  • vagababov
  • yanweiguo
  • ZhiminXiang

Eventing roster

This roster is seeded with all approvers from Eventing workgroups.

  • evankanderson
  • grantr
  • Harwayne
  • lionelvillard
  • matzew
  • n3wscott
  • nachocano
  • slinkydeveloper
  • vaikas

Schedule

Release Release Date Serving Eventing Unpin repos PKG cut
v0.17 2020-08-18 yanweiguo Harwayne - 2020-08-11
v0.18 2020-09-29 ZhiminXiang n3wscott 2020-08-19 2020-09-22
v0.19 2020-11-10 julz n3wscott 2020-09-30 2020-11-03
v0.20 2020-12-22 nak3 slinkydeveloper 2020-11-11 2020-12-15
v0.21 2021-02-02 mattmoor lionelvillard 2020-12-23 2021-01-26
v0.22 2021-03-16 markusthoemmes evankanderson 2020-02-03 2021-03-09
v0.23 2021-04-27 tcnghia vaikas 2020-03-17 2021-04-20
v0.24 2021-06-08 dprotaso matzew 2020-04-28 2021-06-01
v0.25 2021-07-20 vagababov grantr 2020-06-09 2021-07-13
v0.26 2021-08-31 JRBANCEL ... 2020-07-21 2021-08-24

Release instruction

We release the components of Knative every 6 weeks. All of these components must be moved to the latest "release" of all shared dependencies prior to each release.

First week of the rotation

Make sure you have the right permission

Check to make sure you already are in the "Knative Release Leads" team in https://github.com/knative/community/blob/master/peribolos/knative.yaml and https://github.com/knative/community/blob/master/peribolos/knative-sandbox.yaml . If not, send a PR like this one to grant yourself some super power.

Revert all pins to pin master branches again

Revert all pins in all repositories to pin the master branches again, run hack/update-deps.sh --upgrade and PR the changes.

You should only need to do this for knative/{serving,eventing-contrib,eventing} and knative-sandbox/net-{istio,contour,kourier,http01,certmanager}. However, you may want to double check knative/{pkg,caching,networking} as well in case the previous release leads missed a step during their last rotation.

Example PRs:

14 days prior to the release

Announce the imminent pkg cut

Announce on #general that pkg will be cut in a week.

7 days prior to the release

Announce the imminent release cut

Announce on #general that the release will be cut in a week and that additional caution should be used when merging big changes.

Collect release-notes

Make a copy of the last release notes document, empty it out and send it to the WG leads of the respective project (serving or eventing) to fill in. Coordinate with both serving and eventing leads.

Cut release-x.y in test-infra, pkg, caching, and networking libraries

Shared dependencies like knative/{test-infra, pkg, caching, networking} are kept up-to-date nightly in each of the releasing repositories. To stabilize things shortly before the release we cut the release-x.y branches on those 7 days prior to the main release.

First, create a release branch for test-infra named release-x.y.

Next, pkg needs to pin to test-infra's release branch. To do that, edit hack/update-deps.sh in pkg on the newly created branch to pin the branch. Then run ./hack/update-deps.sh --upgrade and commit the changes.

The change to hack/update-deps.sh will look like this:

diff --git a/hack/update-deps.sh b/hack/update-deps.sh
index a39fc858..0634362f 100755
--- a/hack/update-deps.sh
+++ b/hack/update-deps.sh
@@ -26,7 +26,7 @@ cd ${ROOT_DIR}
 # The list of dependencies that we track at HEAD and periodically
 # float forward in this repository.
 FLOATING_DEPS=(
-  "knative.dev/test-infra@master"
+  "knative.dev/[email protected]"
 )

 # Parse flags to determine any we should pass to dep.

PR the changes to each repository respectively, prepending the PR title with [RELEASE].

After test-infra and pkg are pinned, change caching and networking's update-deps.sh to use release-x.y branch of test-infra and pkg. Following that, cut new release-x.y branches for caching and networking.

Pin test-infra, pkg, caching, networking in downstream repositories

Similar to how we pin pkg to test-infra, all downstream users must be pinned to the newly cut release-x.y branches on those libraries. The changes to hack/update-deps.sh look similar to above, but in most cases both dependencies will need to be pinned.

diff --git a/hack/update-deps.sh b/hack/update-deps.sh
index b277dd3ff..1989885ce 100755
--- a/hack/update-deps.sh
+++ b/hack/update-deps.sh
@@ -32,8 +32,8 @@ VERSION="master"
 # The list of dependencies that we track at HEAD and periodically
 # float forward in this repository.
 FLOATING_DEPS=(
-  "knative.dev/test-infra@${VERSION}"
-  "knative.dev/pkg@${VERSION}"
-  "knative.dev/caching@${VERSION}"
-  "knative.dev/networking@${VERSION}"
+  "knative.dev/[email protected]"
+  "knative.dev/[email protected]"
+  "knative.dev/[email protected]"
+  "knative.dev/[email protected]"
 )

The downstream repositories this needs to happen on are:

Apply the changes the the master branches, run hack/update-deps.sh --upgrade (and potentially hack/update-codegen.sh if necessary) and PR the changes to the master branch. Don't cut the release branch yet.

Verify nightly release automation is intact

The automation used to cut the actual releases is the very same as the automation used to cut nightly releases. Verify via testgrid that all relevant nightly releases are passing. If they are not coordinate with the relevant WG leads to fix them.

1 day prior to the release

Confirm readiness

Confirm with the respective WG leads that the release is imminent and obtain green light.

Day of the release

Cut release-x.y branches of serving and eventing

Create a release-x.y branch from master in both repositories. Wait for release automation to kick in (runs on a 2 hour interval). Once the release automation passed, it will create a release tag in both repositories. Enhance the respective tags with the collected release-notes using the Github UI.

Cut release-x.y branches of net-*

Cut a release-x.y branch in each of the following repositories which do not depend on serving or eventing:

Pin serving and eventing releases in dependent repositories

After the tags for serving and eventing are created, their version needs to be pinned in all repositories that depend on them.

For serving that is:

For eventing that is:

The pins are similar to step 5 above, but now we're pinning serving and eventing respectively. Again, the pin PRs are sent against the master branch of each repository respectively.

Cut release-x.y branches of all remaining repositories

After the pin PRs are merged, cut the release-x.y branch in each of the remaining repositories (except operator and client as they are cut separately by the respective working group):

Release automation will automatically pick up the branches and will likewise create the respective tags.

Right after the release

Send a PR like this one to grant ACLs for the next release leads, and to remove yourself from the rotation. Include the next release leads in the PR as a reminder.