text: # 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           | nachocano       | 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](https://github.com/knative/community/pull/209) 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:
  
  - [knative/serving](https://github.com/knative/serving/pull/8579)
  - [knative/eventing](https://github.com/knative/eventing/pull/3546)
  - [knative/eventing-contrib](https://github.com/knative/eventing-contrib/pull/1272)
  - [knative-sandbox/net-istio](https://github.com/knative-sandbox/net-istio/pull/172)
  - [knative-sandbox/net-contour](https://github.com/knative-sandbox/net-contour/pull/154)
  - [knative-sandbox/net-kourier](https://github.com/knative-sandbox/net-kourier/pull/84)
  - [knative-sandbox/net-http01](https://github.com/knative-sandbox/net-http01/pull/42)
  - [knative-sandbox/net-certmanager](https://github.com/knative-sandbox/net-certmanager/pull/39)
  
  ## 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](https://docs.google.com/document/d/1FTL_fMXU2hv2POh9uN_8IJe9FbqEIzFdRZZRXI0WaT4/edit),
  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
  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/test-infra@release-x.y"
   )
  
   # 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
  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/test-infra@release-x.y"
  +  "knative.dev/pkg@release-x.y"
  +  "knative.dev/caching@release-x.y"
  +  "knative.dev/networking@release-x.y"
   )
  ```
  
  The downstream repositories this needs to happen on are:
  
  - [knative/client](https://github.com/knative/client)
  
  - [knative/operator](https://github.com/knative/operator)
  
  - [knative/serving](https://github.com/knative/serving)
  - [knative-sandbox/net-certmanager](https://github.com/knative-sandbox/net-certmanager)
  - [knative-sandbox/net-contour](https://github.com/knative-sandbox/net-contour)
  - [knative-sandbox/net-http01](https://github.com/knative-sandbox/net-http01)
  - [knative-sandbox/net-istio](https://github.com/knative-sandbox/net-istio)
  - [knative-sandbox/net-kourier](https://github.com/knative-sandbox/net-kourier)
  
  - [knative/eventing](https://github.com/knative/eventing)
  - [knative/eventing-contrib](https://github.com/knative/eventing-contrib)
  - [knative-sandbox/eventing-kafka-broker](https://github.com/knative-sandbox/eventing-kafka-broker)
  - [knative-sandbox/discovery](https://github.com/knative-sandbox/discovery)
  - [knative-sandbox/eventing-autoscaler-keda](https://github.com/knative-sandbox/eventing-autoscaler-keda)
  - [knative-sandbox/eventing-awssqs](https://github.com/knative-sandbox/eventing-awssqs)
  - [knative-sandbox/eventing-camel](https://github.com/knative-sandbox/eventing-camel)
  - [knative-sandbox/eventing-ceph](https://github.com/knative-sandbox/eventing-ceph)
  - [knative-sandbox/eventing-couchdb](https://github.com/knative-sandbox/eventing-couchdb)
  - [knative-sandbox/eventing-github](https://github.com/knative-sandbox/eventing-github)
  - [knative-sandbox/eventing-gitlab](https://github.com/knative-sandbox/eventing-gitlab)
  - [knative-sandbox/eventing-kafka](https://github.com/knative-sandbox/eventing-kafka)
  - [knative-sandbox/eventing-natss](https://github.com/knative-sandbox/eventing-natss)
  - [knative-sandbox/eventing-prometheus](https://github.com/knative-sandbox/eventing-prometheus)
  - [knative-sandbox/eventing-rabbitmq](https://github.com/knative-sandbox/eventing-rabbitmq)
  
  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`:
  
  - [knative-sandbox/net-certmanager](https://github.com/knative-sandbox/net-certmanager)
  - [knative-sandbox/net-contour](https://github.com/knative-sandbox/net-contour)
  - [knative-sandbox/net-http01](https://github.com/knative-sandbox/net-http01)
  - [knative-sandbox/net-istio](https://github.com/knative-sandbox/net-istio)
  
  ### 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:
  
  - [knative-sandbox/net-kourier](https://github.com/knative-sandbox/net-kourier)
  - [knative/eventing-contrib](https://github.com/knative/eventing-contrib)
  
  For **eventing** that is:
  
  - [knative/eventing-contrib](https://github.com/knative/eventing-contrib)
  - [knative-sandbox/eventing-kafka-broker](https://github.com/knative-sandbox/eventing-kafka-broker)
  
  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`):
  
  - [knative-sandbox/net-kourier](https://github.com/knative-sandbox/net-kourier)
  - [knative/eventing-contrib](https://github.com/knative/eventing-contrib)
  - [knative-sandbox/eventing-kafka-broker](https://github.com/knative-sandbox/eventing-kafka-broker)
  
  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](https://github.com/knative/community/pull/209) 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.
  
  ---
  