For all releases Create prepare-release/x.y.z Branch
[x] 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
[x] Create the prepare-release branch for the version (e.g. prepare-release/2.7.1): git branch -m prepare-release/2.7.1
[x] 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.
[x] 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.
[x] 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).
[x] Ensure base manifest versions use the new version (config/image/enterprise/kustomization.yaml and config/image/oss/kustomization.yaml) and update manifest files: make manifests
[x] Push the branch up to the remote: git push --set-upstream origin prepare-release/x.y.z
[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 the main branch for major or minor release, for patch use the release branch. Your tag must use vX.Y.Z format. Set latest 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.
[x] 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.
[x] The release workflow (.github/workflows/release.yaml) will update the latest branch - if the released version was set to be latest - 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. Note that you will need to update the new version's navigation manifest (e.g. for 2.7 to use the new files (CRDs and CLI arguments references) after.
[ ] 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 to app/_data/docs_nav_kic_NEWVERSION.yml and update the release field to NEWVERSION. Add entries for any new articles.
[ ] Make sure that app/_data/docs_nav_kic_NEWVERSION.yml links to the latest generated custom-resources-X.X.X.md.
[ ] Add a section to app/_data/kong_versions.yml for your version and move the latest field to version that's being released.
[ ] Add entries in support policy documents: app/_src/kubernetes-ingress-controller/support-policy.md and app/_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
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.
pmalek
commented
1 month ago
Release Type
patch
For all releases Create
prepare-release/x.y.zBranchmain:git checkout main; git pullor a targeted release branch e.g.release/2.7.x:git checkout release/2.7.x; git pullprepare-releasebranch for the version (e.g.prepare-release/2.7.1):git branch -m prepare-release/2.7.1config/image/enterprise/kustomization.yamlandconfig/image/oss/kustomization.yaml) and update manifest files:make manifestsgit push --set-upstream origin prepare-release/x.y.zFor all releases Create a Release Pull Request
ci/run-e2elabel on the PR preparing the release.main. Set abackport release/X.Y.Zlabel.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).prepare-release/x.y.zbranch will get automatically removed), approve and merge the automatic backport PR and initiate a release job on themainbranch for major or minor release, for patch use the release branch. Your tag must usevX.Y.Zformat. Setlatestto 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.latestbranch - if the released version was set to belatest- to the just released tag.For major/minor releases Create
release/<MAJOR>.<MINOR>.xBranchrelease/<MAJOR>.<MINOR>.xbranch 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
app/_includes/md/kic/crd-ref/. This is a brief description injected into the CRD reference page.reference/version-compatibility.mdto include the new versions (make sure you capture any new Kubernetes/Istio versions that have been tested)app/_data/docs_nav_kic_OLDVERSION.ymltoapp/_data/docs_nav_kic_NEWVERSION.ymland update thereleasefield toNEWVERSION. Add entries for any new articles.app/_data/docs_nav_kic_NEWVERSION.ymllinks to the latest generatedcustom-resources-X.X.X.md.app/_data/kong_versions.ymlfor your version and move thelatestfield to version that's being released.app/_src/kubernetes-ingress-controller/support-policy.mdandapp/_includes/md/kic/support.md.For major/minor releases only Bump charts' dependencies
config/crd/baseswith [kong/kongcharts CRDs][https://github.com/Kong/charts/blob/6c1421bf2f4/charts/kong/crds/custom-resource-definitions.yaml]kong.kubernetesRBACRulestemplate) in [kong/kong'scharts/kong/templates][https://github.com/Kong/charts/blob/0b1f635f180220f86d17f5b1b4dd60fc0dc35aae/charts/kong/templates/_helpers.tpl#L1292].kong/kongHelm chart.kong/kongHelm chart.kong/kongis released, bump the dependency onkong/kongchart in thekong/ingressHelm 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