Kueue V0.14.3 Release: Discussion & Checklist

by Admin 46 views
Kueue v0.14.3 Release: Discussion & Checklist

Hey everyone! Let's dive into the release process for Kueue v0.14.3. This document outlines the checklist and discussion points for this release. We'll walk through each step, making sure everything is smooth and well-documented.

Release Checklist

This checklist is crucial to ensure a successful release. Let's go through each item meticulously.

Please do not remove items from the checklist

  • [ ] OWNERS must LGTM the release proposal. At least two approvers are needed for minor or major releases, and at least one for a patch release. This is a critical step to ensure we have the necessary approvals before proceeding. LGTM (Looks Good To Me) from the owners signifies that the proposal has been reviewed and is approved.

  • [ ] Verify that the changelog in this issue and the CHANGELOG folder is up-to-date.

    • [ ] Use release-notes tool to gather notes. Keeping the changelog updated ensures transparency and helps users understand what’s new in this release. We need to accurately reflect all changes, bug fixes, and new features. 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 (vMAJ.MAJ.MIN.0), create a new release branch.

    • [ ] An OWNER creates a vanilla release branch with git branch release-$MAJ.$MIN main. Creating a new release branch isolates the release-specific changes from the main development line. This helps in stabilizing the release without disrupting ongoing development.
    • [ ] An OWNER pushes the new release branch with git push upstream release-$MAJ.$MIN. Pushing the branch to the upstream repository makes it accessible to all collaborators and the CI/CD system.

  • [ ] Update the release branch:

    • [ ] Update RELEASE_BRANCH and RELEASE_VERSION in Makefile and run make prepare-release-branch. Updating these variables in the Makefile ensures that the build and release processes use the correct branch and version information.
    • [ ] Update the CHANGELOG. The changelog should accurately reflect all changes included in the release.
    • [ ] Submit a pull request with the changes: . A pull request allows for peer review and ensures that all changes are properly vetted before being merged.

  • [ ] 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. Signed tags provide cryptographic proof of the release’s origin and integrity. This is a critical security measure.

  • [ ] An OWNER pushes the tag with git push upstream $VERSION.

    • [ ] Triggers prow to build and publish a staging container image us-central1-docker.pkg.dev/k8s-staging-images/kueue/kueue:$VERSION. Pushing the tag triggers the CI/CD system to build and publish a staging container image. This allows for testing and validation of the release candidate.

  • [ ] An OWNER prepares a draft release.

    • [ ] Create the draft release pointing to the created tag. Draft releases allow for preparing release notes, artifacts, and other metadata before making the release public.
    • [ ] Write the changelog into the draft release. The changelog provides users with a clear overview of what’s new and changed in the release.
    • [ ] Run make artifacts IMAGE_REGISTRY=registry.k8s.io/kueue GIT_TAG=$VERSION to generate the artifacts in the artifacts folder. Generating artifacts ensures that all necessary files are packaged and available for distribution.
    • [ ] Upload the files in the artifacts folder to the draft release - either via UI or gh release --repo kubernetes-sigs/kueue upload $VERSION artifacts/*. Uploading artifacts to the draft release makes them available for users to download and use.

  • [ ] Submit a PR against k8s.io to promote the container images and Helm Chart to production:

    • [ ] Update registry.k8s.io/images/k8s-staging-kueue/images.yaml. Promoting the container images and Helm chart to production makes the release available to a wider audience.

  • [ ] Wait for the PR to be merged and verify that the image registry.k8s.io/kueue/kueue:$VERSION is available. Verifying the image ensures that it has been successfully promoted and is available for use.

  • [ ] Publish the draft release prepared at the GitHub releases page. Link: . Publishing the release makes it public and accessible to users.

  • [ ] Run the openvex action to generate openvex data. The action will add the file to the release artifacts. Generating OpenVEX data provides a standardized way to communicate vulnerabilities associated with the release.

  • [ ] Run the SBOM action to generate the SBOM and add it to the release. Generating a Software Bill of Materials (SBOM) provides a comprehensive list of components included in the release, enhancing transparency and security.

  • [ ] Update the main branch:

    • [ ] Update RELEASE_VERSION in Makefile and run make prepare-release-branch. Updating the RELEASE_VERSION in the Makefile ensures that the main branch is ready for the next development cycle.
    • [ ] Release notes in the CHANGELOG. The changelog should reflect any changes made during the release process.
    • [ ] SECURITY-INSIGHTS.yaml values by running make update-security-insights GIT_TAG=$VERSION. Updating the security insights file ensures that any security-related information is up-to-date.
    • [ ] Submit a pull request with the changes: . A pull request allows for peer review and ensures that all changes are properly vetted before being merged into the main branch.
    • [ ] Cherry-pick the pull request onto the website branch. Cherry-picking the changes to the website branch ensures that the documentation is up-to-date with the latest release.

  • [ ] For major or minor releases, merge the main branch into the website branch to publish the updated documentation. Merging the main branch into the website branch ensures that the documentation reflects the latest changes and features.

  • [ ] Send an announcement email to sig-scheduling@kubernetes.io and wg-batch@kubernetes.io with the subject [ANNOUNCE] kueue $VERSION is released. . Sending an announcement email informs the community about the new release and its features.

  • [ ] 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=v$MAJ.$(($MIN+1)).0-devel; git tag $DEVEL main && git push upstream $DEVEL

      This ensures that the devel builds on the main branch will have a meaningful version number. Creating a development tag helps in versioning the pre-release builds.

    • [ ] Create a milestone for the next minor release and update prow to set it automatically for new PRs: . Creating a milestone helps in tracking progress towards the next release.

    • [ ] Create the presubmits and the periodic jobs for the next patch release: . Setting up presubmits and periodic jobs ensures continuous testing and validation of the codebase.

    • [ ] Drop CI Jobs for testing the out-of-support branch: . Dropping CI jobs for out-of-support branches helps in optimizing resources and focusing on active branches.

Detailed Breakdown of Key Steps

Let's break down some of the key steps in more detail to ensure we're all on the same page. This section will provide additional context and guidance for each task.

1. Approvals from OWNERS

Getting approvals from the OWNERS is the first and foremost step. It ensures that the release has been reviewed by the core team members. For minor or major releases, we need at least two approvals, while a patch release requires at least one. This process helps in maintaining the quality and stability of the releases. The OWNERS file lists the individuals who have the authority to approve changes and releases. Their LGTM (Looks Good To Me) signifies that the proposal meets the project's standards and is safe to proceed.

2. Changelog Verification

The changelog is a critical piece of documentation. It provides a summary of all the changes included in the release. Keeping it up-to-date ensures that users can easily understand what's new and improved. We use the release-notes tool to gather notes, making the process more efficient. This tool helps in automatically generating release notes based on the commit messages and pull requests merged since the last release. Accurately maintaining the changelog builds trust with our users and helps them in adopting the new release more confidently.

3. Branching Strategy

For major or minor releases, creating a new release branch is essential. This isolates the release-specific changes from the main development line. An OWNER creates a vanilla release branch using git branch release-$MAJ.$MIN main and pushes it to the upstream repository. This branching strategy allows us to stabilize the release without disrupting ongoing development on the main branch. It provides a dedicated space for bug fixes, documentation updates, and other release-related tasks.

4. Updating the Release Branch

Once the release branch is created, we need to update it. This involves modifying the Makefile to reflect the correct release branch and version, updating the CHANGELOG, and submitting a pull request with these changes. The Makefile contains important configuration settings, including the release branch and version. Updating it ensures that the build and release processes use the correct information. The pull request allows for a thorough review of the changes before they are merged, ensuring that everything is in order.

5. Tagging the Release

Creating a signed tag is a crucial security measure. It provides cryptographic proof of the release's origin and integrity. An OWNER creates a signed tag using git tag -s $VERSION and inserts the changelog into the tag description. This step requires a PGP key registered on GitHub. Signed tags ensure that the release has not been tampered with and can be trusted. This is particularly important for users who rely on Kueue in production environments.

6. Generating Artifacts

Generating artifacts involves packaging all the necessary files for distribution. We use the command make artifacts IMAGE_REGISTRY=registry.k8s.io/kueue GIT_TAG=$VERSION to generate these artifacts. The artifacts are placed in the artifacts folder and then uploaded to the draft release. This step ensures that users have access to all the required files, including binaries, manifests, and other resources, to deploy and use Kueue.

7. Promoting Container Images and Helm Chart

Promoting container images and the Helm chart to production makes the release available to a wider audience. This involves submitting a pull request against the k8s.io repository and updating the registry.k8s.io/images/k8s-staging-kueue/images.yaml file. This step ensures that users can easily access and deploy Kueue using standard Kubernetes tools and practices. It also helps in maintaining consistency and reliability across different environments.

8. Publishing the Release

Publishing the draft release makes it public and accessible to users. This is done via the GitHub releases page. Before publishing, we ensure that all the artifacts have been uploaded, the changelog is accurate, and the release notes are complete. Publishing the release signals that it is ready for use and provides users with a stable and well-documented version of Kueue.

9. Generating OpenVEX and SBOM Data

Generating OpenVEX and SBOM (Software Bill of Materials) data enhances the security and transparency of the release. OpenVEX provides a standardized way to communicate vulnerabilities, while SBOM provides a comprehensive list of components included in the release. These steps help users understand the security posture of the release and make informed decisions about its usage. They are increasingly important for meeting compliance requirements and building trust in the software supply chain.

10. Updating the Main Branch

Updating the main branch ensures that it is ready for the next development cycle. This involves updating the RELEASE_VERSION in the Makefile, updating the changelog, and updating the SECURITY-INSIGHTS.yaml file. A pull request is then submitted with these changes, allowing for review and validation. Updating the main branch ensures that it remains consistent with the released version and provides a solid foundation for future development efforts.

11. Preparing for the Next Version

Preparing the repository for the next version involves creating a development tag, creating a milestone for the next minor release, and setting up presubmits and periodic jobs for the next patch release. These steps ensure that the project is well-prepared for future development and releases. They help in tracking progress, maintaining code quality, and ensuring continuous testing and validation.

Changelog

Describe changes since the last release here.

Please fill in the changes since the last release in the above section. This is where we'll document all the specific updates, bug fixes, and new features included in v0.14.3. Make sure to be detailed and user-friendly!

Let's work together to make this release a success, guys! Feel free to add any comments, questions, or suggestions below. Your input is highly valued!