NEW_RELEASE.md

name	about	title	assignees
New Release	Propose a new release	Release v0.x.0	ahg-g, alculquicondor, tenzen-y

Release Checklist

• OWNERS must LGTM the release proposal. At least two for minor or major releases. At least one for a patch release.
• Verify that the changelog in this issue and the CHANGELOG folder is up-to-date
  • Use https://github.com/kubernetes/release/tree/master/cmd/release-notes to gather notes. Example: release-notes --org kubernetes-sigs --repo kueue --branch release-0.3 --start-sha 4a0ebe7a3c5f2775cdf5fc7d60c23225660f8702 --end-sha a51cf138afe65677f5f5c97f8f8b1bc4887f73d2 --dependencies=false --required-author=""
• For major or minor releases (v$MAJ.$MIN.0), create a new release branch.
  • An OWNER creates a vanilla release branch with git branch release-$MAJ.$MIN main
  • An OWNER pushes the new release branch with git push release-$MAJ.$MIN
• Update the release branch:
  • Update RELEASE_BRANCH and RELEASE_VERSION in Makefile and run make prepare-release-branch
  • Update the CHANGELOG
  • Submit a pull request with the changes:
• An OWNER prepares a draft release
  • Write the change log into the draft release.
  • Run make artifacts IMAGE_REGISTRY=registry.k8s.io/kueue GIT_TAG=$VERSION to generate the artifacts and upload the files in the artifacts folder to the draft release.
• An OWNER creates a signed tag running git tag -s $VERSION and inserts the changelog into the tag description. To perform this step, you need a PGP key registered on github.
• An OWNER pushes the tag with git push $VERSION
  • Triggers prow to build and publish a staging container image us-central1-docker.pkg.dev/k8s-staging-images/kueue/kueue:$VERSION
• Submit a PR against k8s.io, updating registry.k8s.io/images/k8s-staging-kueue/images.yaml to promote the container images to production:
• Wait for the PR to be merged and verify that the image registry.k8s.io/kueue/kueue:$VERSION is available.
• Publish the draft release prepared at the GitHub releases page. Link:
• Run the openvex action to generate openvex data. The action will add the file to the release artifacts.
• Run the SBOM action to generate the SBOM and add it to the release.
• For major or minor releases, merge the main branch into the website branch to publish the updated documentation.
• Send an announcement email to sig-scheduling@kubernetes.io and wg-batch@kubernetes.io with the subject [ANNOUNCE] kueue $VERSION is released.
• Update the below files with respective values in main branch :
  • Latest version in README.md
  • Latest version in cmd/experimental/kjobctl/docs/installation.md
  • Release notes in the CHANGELOG
  • version in site/hugo.toml
  • appVersion in charts/kueue/Chart.yaml
  • SECURITY-INSIGHTS.yaml values by running make update-security-insights GIT_TAG=$VERSION
• For a major or minor release, prepare the repo for the next version:
  • Create an unannotated devel tag in the main branch, on the first commit that gets merged after the release branch has been created (presumably the README update commit above), and, push the tag: DEVEL=v0.$(($MAJ+1)).0-devel; git tag $DEVEL main && git push $DEVEL This ensures that the devel builds on the main branch will have a meaningful version number.
  • Create a milestone for the next minor release and update prow to set it automatically for new PRs:
  • Create the presubmits jobs for the next patch release:

Changelog

Describe changes since the last release here.