Open
Description
Release Type
patch
For all releases Create prepare-release/x.y.z
Branch
- Ensure that you have up to date copy of
main
:git checkout main; git pull
or a targeted release branch e.g.release/2.7.x
:git checkout release/2.7.x; git pull
- Create the
prepare-release
branch for the version (e.g.prepare-release/2.7.1
):git branch -m prepare-release/2.7.1
- Review carefully CHANGELOG.md. Manually reorder entries for relevance, common topic, adjust description, etc. - make it clear and easy to follow for users. Optionally headline notable changes (emojis are allowed). Double-check that dates are correct, that link anchors point to the correct header, and that you've included a link to the GitHub compare link at the end. If there were any RC releases before this version, fold their changes into the final release entry.
- Resolve all licensing issues that FOSSA has detected. Go to Issues tab in FOSSA's KIC project and resolve every issue, inspecting if it's a false positive or not. ignored.go script should be useful to look for issues that have been already resolved and reappeared due to version changes.
- Update ignored.json following instructions in README.
- Retrieve the latest license report from FOSSA and save it to LICENSES (go to Reports tab in FOSSA's KIC project, select 'plain text' format, tick 'direct dependencies' and download it).
- Ensure base manifest versions use the new version (
config/image/enterprise/kustomization.yaml
andconfig/image/oss/kustomization.yaml
) and update manifest files:make manifests
- Push the branch up to the remote:
git push --set-upstream origin prepare-release/x.y.z
For all releases Create a Release Pull Request
- Check the latest E2E nightly test run to confirm that E2E tests are succeeding. If you are backporting features into a non-main branch, run a targeted E2E job against that branch or use
ci/run-e2e
label on the PR preparing the release. - Open a PR from your branch to
main
. Set abackport release/X.Y.Z
label. - If this is a patch release, ensure that the release branch (e.g.
release/2.9.x
) compared against the latest patch for this minor release (e.g.v2.9.0
) includes the expected changes that the release should include (e.g. by checking https://github.com/kong/kubernetes-ingress-controller/compare/v2.9.0..release/2.9.x). - Once the PR is merged (the
prepare-release/x.y.z
branch will get automatically removed), approve and merge the automatic backport PR and initiate a release job on themain
branch for major or minor release, for patch use the release branch. Your tag must usevX.Y.Z
format. Setlatest
to true if this is be the latest release. That should be the case if a new major.minor release is done or a patch release is done on the latest minor version. - CI will validate the requested version, build and push an image, and run tests against the image before finally creating a tag and publishing a release. If tests fail, CI will push the image but not the tag or release. Investigate the failure, correct it as needed, and start a new release job.
- The release workflow (.github/workflows/release.yaml) will update the
latest
branch - if the released version was set to belatest
- to the just released tag.
For major/minor releases Create release/<MAJOR>.<MINOR>.x
Branch
- Create the
release/<MAJOR>.<MINOR>.x
branch at the place where you want to branch of off main. It should be done after the release workflow has run successfully.
For major/minor releases only Update Release documents
- Trigger release_docs workflow.
- Ensure a draft PR is created in docs.konghq.com repository.
- If you are adding a new CRD, add a new description file under
app/_includes/md/kic/crd-ref/
. This is a brief description injected into the CRD reference page. - Update articles in the new version as needed.
- Update
reference/version-compatibility.md
to include the new versions (make sure you capture any new Kubernetes/Istio versions that have been tested) - Copy
app/_data/docs_nav_kic_OLDVERSION.yml
toapp/_data/docs_nav_kic_NEWVERSION.yml
and update therelease
field toNEWVERSION
. Add entries for any new articles. - Make sure that
app/_data/docs_nav_kic_NEWVERSION.yml
custom resources link to the latest generatedcustom-resources-X.X.X.md
. - Make sure that
app/_data/docs_nav_kic_NEWVERSION.yml
cli arguments link to the latest generatedcli-arguments-X.X.X.md
. - Create the nav page for the next release in
app/_data/docs_nav_kic_NEXTVERSION.yml
. However, don't update yet its links tocustom-resources-X.X.X.md
andcli-arguments-X.X.X.md
, as it will be part of the next release process. - Add a section to
app/_data/kong_versions.yml
for your version and move thelatest
field to version that's being released. - Add entries in support policy documents:
app/_src/kubernetes-ingress-controller/support-policy.md
andapp/_includes/md/kic/support.md
. - Mark the PR ready for review.
- Inform and ping the @Kong/team-k8s via slack of impending release with a link to the release PR.
- Ensure that KGO works with the released version of KIC. Update and release it if needed.
For major/minor releases only Bump charts' dependencies
- Synchronize
config/crd/bases
with [kong/kong
charts CRDs][https://github.com/Kong/charts/blob/6c1421bf2f4/charts/kong/crds/custom-resource-definitions.yaml] - Update RBAC policy rules (
kong.kubernetesRBACRules
template) in [kong/kong
'scharts/kong/templates
][https://github.com/Kong/charts/blob/0b1f635f180220f86d17f5b1b4dd60fc0dc35aae/charts/kong/templates/_helpers.tpl#L1292]. - Bump the KIC version in the
kong/kong
Helm chart. - Release new version of the
kong/kong
Helm chart. - After
kong/kong
is released, bump the dependency onkong/kong
chart in thekong/ingress
Helm chart and release a new version of the chart.
Conformance tests report
Trigger for released version CI workflow Generate Kubernetes Gateway API conformance tests report, verify artifact and submit it to https://github.com/kubernetes-sigs/gateway-api/tree/main/conformance/reports. Update the KIC version in the README's Gateway API conformance badge.
Post release testing
Appoint volunteer(s) to perform end-to-end testing of newly released features by following official documentation. Testing should cover following all the newly added or modified guides/tutorials, etc.
Release Troubleshooting
The Release Troubleshooting guide covers strategies for dealing with a release that has failed.
For major/minor releases only Do post release steps
- Schedule a retro meeting. Invite the team ([email protected]) and a Product Manager. Remember to link to retro notes in the invite description.
- Update
konnect-ui-apps
with latest KIC version (see konnect-ui-apps#4939 as an example). Remove this when #6738 is resolved.