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.
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.
This roster is seeded with all approvers from Serving workgroups.
- dprotaso
- julz
- JRBANCEL
- markusthoemmes
- mattmoor
- nak3
- tcnghia
- vagababov
- yanweiguo
- ZhiminXiang
This roster is seeded with all approvers from Eventing workgroups.
- evankanderson
- grantr
- Harwayne
- lionelvillard
- matzew
- n3wscott
- nachocano
- slinkydeveloper
- vaikas
| 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 |
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.
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 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
- knative/eventing
- knative/eventing-contrib
- knative-sandbox/net-istio
- knative-sandbox/net-contour
- knative-sandbox/net-kourier
- knative-sandbox/net-http01
- knative-sandbox/net-certmanager
Announce on #general that pkg will be cut in a week.
Announce on #general that the release will be cut in a week and that additional caution should be used when merging big changes.
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.
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.
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.
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.
Confirm with the respective WG leads that the release is imminent and obtain green light.
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 a release-x.y branch in each of the following repositories which do not
depend on serving or eventing:
- knative-sandbox/net-certmanager
- knative-sandbox/net-contour
- knative-sandbox/net-http01
- knative-sandbox/net-istio
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.
After the pin PRs are merged, cut the release-x.y branch in each of the
remaining repositories (except operator):
Release automation will automatically pick up the branches and will likewise create the respective tags.
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.