This document includes the roster, instructions and timetable to perform a Knative release.
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
- nak3
- tcnghia
- yanweiguo
- ZhiminXiang
This roster is seeded with all approvers from Eventing workgroups.
- evankanderson
- lionelvillard
- matzew
- n3wscott
- 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 | 2021-01-12 | nak3 | slinkydeveloper | 2020-11-11 | 2021-01-07 |
| v0.21 | 2021-02-23 | mattmoor | lionelvillard | 2021-01-13 | 2021-02-16 |
| v0.22 | 2021-04-06 | markusthoemmes | evankanderson | 2021-02-24 | 2021-03-30 |
| v0.23 | 2021-05-18 | tcnghia | vaikas | 2021-04-07 | 2021-05-11 |
| v0.24 | 2021-06-29 | dprotaso | matzew | 2021-05-19 | 2021-06-22 |
| v0.25 | 2021-08-10 | JRBANCEL | ... | 2021-06-30 | 2021-08-03 |
| v0.26 | 2021-09-21 | ... | ... | 2021-08-11 | 2021-09-14 |
NOTE: v0.20 is moved by 3 weeks for end of year holidays
Below you'll find the instructions to release a knative.dev repository.
For more information on the timetable, jump to the Timetable paragraph.
Releasing a repository includes:
- Aligning the
knative.devdependencies to the other release versions on main - Creating a new branch starting from main for the release (e.g.
release-0.20) - Execute the job on Prow that builds the code from the release branch, tags the revision, publishes the images, publishes the yaml artifacts and generates the Github release.
Most of the above steps are automated, although in some situations it might be necessary to perform some of them manually.
Before beginning, check if the repository is in a good shape and the builds pass consistently. This is required because the Prow job that builds the release artifacts will execute all the various tests (build, unit, e2e) and, if something goes wrong, you will probably need to restart this process from the beginning.
For any problems in a specific repo, get in touch with the relevant WG leads to fix them.
In order to align the knative.dev dependencies, knobots will perform PRs like
this for each repo, executing
the command ./hack/update-deps.sh --upgrade --release 0.20 and committing all
the content.
If no dependency bump PR is available, you can:
- Manually trigger the generation of these PRs starting the Knobots Auto Updates workflow and wait for the PR to pop in the repo you need.
- Execute the script below on your machine and PR the result to main:
RELEASE=0.20
REPO=git@github.com:knative/example.git
tmpdir=$(dirname $(mktemp -u))
cd ${tmpdir}
git clone ${REPO}
cd "$(basename "${REPO}" .git)"
./hack/update-deps.sh --upgrade --release ${RELEASE}
./hack/update-codegen.sh
# If there are no changes, you can go to the next step without committing any change.
# Otherwise, commit all the changes
git statusAt this point, you can proceed with the releasability check. A releasability check is executed periodically and posts the result on the Slack release channel and it fails if the dependencies are not properly aligned. If you don't want to wait, you can manually execute the Releasability workflow.
If the releasability reports NO-GO, probably there is some deps misalignment, hence you need to go back to the previous step and check the dependencies, otherwise, you're ready to proceed.
You can execute the releasability check locally using buoy:
RELEASE=0.20
REPO=git@github.com:knative/example.git
tmpdir=$(dirname $(mktemp -u))
cd ${tmpdir}
git clone ${REPO}
cd "$(basename "${REPO}" .git)"
if buoy check go.mod --domain knative.dev --release ${RELEASE} --verbose; then
git checkout -b release-${RELEASE}
./hack/update-deps.sh --upgrade --release ${RELEASE}
git status
fiIf there are changes, then it's NO-GO, otherwise it's GO
After the dependencies are aligned and releasability is ready to GO, perform one
last check manually that every knative.dev in the go.mod file is properly
configured:
- For the support repos (
hack,test-infra,pkg, etc) you should see the dependency version pointing at a revision which should match theHEADof the release branch. E.g.knative.dev/pkg v0.0.0-20210112143930-acbf2af596cfpoints at the revisionacbf2af596cf, which is theHEADof therelease-0.20branch inpkgrepo. - For the release repos, you should see the dependency version pointing at the
version tag. E.g.
knative.dev/eventing v0.20.0points at the tagv0.20.0in theeventingrepo.
Now you're ready to create the release-v.y branch. This can be done by using
the GitHub UI:
-
Click on the branch selection box at the top level page of the repository.
-
Search for the correct
release-x.ybranch name for the release.
-
Click "Create branch: release-x.y".
Otherwise, you can do it by hand on your local machine.
After a release-x.y branch exists, a 4 hourly prow job will build the code
from the release branch, tag the revision, publish the images, publish the yaml
artifacts and generate the Github release. Update the description of the release
with the release notes collected.
You can manually trigger the release:
-
Navigate to https://prow.knative.dev/
-
Search for the
*-auto-releasejob for the repository.
-
Rerun the auto-release job.
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.
In case you cut a branch before it was ready (e.g. some deps misalignment, a failing test, etc), you can try to restart this process. But first, clean up the repo in this order:
- Remove the Github release (if any)
- Remove the git tag (if any) using
git push --delete origin v0.20.0(assumingoriginis theknative.devrepo) - Remove the git branch (if any) from the Github UI
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/main/peribolos/knative.yaml and https://github.com/knative/community/blob/main/peribolos/knative-sandbox.yaml . If not, send a PR like this one to grant yourself some super power.
Ask someone from the TOC to create a release-# Slack channel that will be
used to help manage this release.
Update the defaults in knative-releasability.yaml to this release. These changes will be propagated to the rest of Knative in the next round of workflow syncs.
Announce on #general that pkg will be cut in a week.
The supporting repos are the base repos where we have common code and common scripts. For these repos, we follow the same release process as explained in release a repository, but no prow job is executed, hence no git tag and Github release are produced.
Follow the release a repository guide, skipping the prow job part, starting with the hack repo:
After hack:
| Repo | Releasability |
|---|---|
| knative.dev/pkg |  |
| knative.dev/test-infra |  |
After pkg:
| Repo | Releasability |
|---|---|
| knative.dev/networking |  |
| knative.dev/caching |  |
| knative.dev/reconciler-test |  |
Automation will propagate these updates to all the downstream repos in the next
few cycles. The goal is to have the first wave of repo releases (serving,
eventing, etc) to become "releasabile" by the end of the week. This is
signaled via the Slack report of releasability posted to the release-#
channel every morning (5am PST, M-F).
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 new HackMD release notes document. 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.
Each repo has a Release Notes GitHub Action workflow. This can be used to
generate the starting point for the release notes. See an example in
Eventing.
The default starting and ending SHAs will work if running out of the main
branch, or you can determine the correct starting and ending SHAs for the script
to run.
Confirm with the respective WG leads that the release is imminent and obtain green light.
Follow the release a repository instructions for each repo. 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 the repository. Enhance the respective tags with the collected release-notes using the GitHub UI.
In general the release dependency order is something like the following (as of
v0.20). Note: buoy check will fail if the dependencies are not yet ready.
First:
After eventing:
After both eventing and serving:
| Repo | Release | Releasability | Nightly |
|---|---|---|---|
| knative.dev/eventing-redis |  |
 |
 |
| knative.dev/eventing-github |  |
 |
 |
| knative.dev/eventing-gitlab |  |
 |
 |
Lastly:
| Repo | Release | Releasability | Nightly |
|---|---|---|---|
| knative.dev/eventing-autoscaler-keda |  |
 |
 |
We have a few repos inside of Knative that are not handled in the standard process at the moment. They might have additional dependencies or depend on the releases existing. Skip these. Special cases are:
| Repo | Release | Releasability | Nightly |
|---|---|---|---|
| knative.dev/client |  |
 |
 |
| knative.dev/docs |  |
 |
N/A |
| knative.dev/operator |  |
 |
N/A |
| knative.dev/website | N/A | N/A | N/A |
Watch for the PR like this one to enable dot releases on the new releases and approve it.
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.
Send a PR like this one to bump knobots auto release workflow to the next release.