Release v0.10.0

[GiuseppeTT]

Release Checklist

• All OWNERS must LGTM the release proposal
• Verify that the changelog in this issue is up-to-date
• For major or minor releases (v$MAJ.$MIN.0), create a new release branch.
  • Note: https://github.com/kubernetes-sigs/jobset/tree/release-0.10
  • 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 BRANCH_NAME in the Makefile and set export VERSION=vX.Y.Z.
  • Note: Run prepare release script and update changelog #1044
  • Run make prepare-release-branch to update the assets.
  • Update the CHANGELOG-X.Y
  • Submit a PR with the changes against the release branch <!-- TODO (andreyvelich): Add example here>
• After the above PR is merged rebase your local branch and create 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
    gcr.io/k8s-staging-jobset/jobset:$VERSION
• An OWNER prepares a draft release
  • Write the changelog into the draft release.
  • Run make artifacts IMAGE_REGISTRY=registry.k8s.io/jobset
    to generate the artifacts and upload the files in the artifacts folder
    to the draft release.
• Submit a PR against k8s.io,
  updating k8s.gcr.io/images/k8s-staging-jobset/images.yaml to
  promote the container images
  to production:
  • Note: Promote images for jobset v0.10.0 kubernetes/k8s.io#8569
• Wait for the PR to be merged and verify that the image registry.k8s.io/jobset/jobset:$VERSION is available.
• Wait for the PR to be merged and verify that the chart registry.k8s.io/jobset/charts/jobset is available.
  Try `helm show chart oci://registry.k8s.io/jobset/charts/jobset --version ${VERSION/#v/}
• Publish the draft release prepared at the Github releases page.
• Add a link to the tagged release in this issue:
• Send an announcement email to sig-apps@kubernetes.io, sig-scheduling@kubernetes.io and wg-batch@kubernetes.io with the subject [ANNOUNCE] JobSet $VERSION is released
• Add a link to the release announcement in this issue:
• For a major or minor release, update README.md in main branch: <!-- TODO (andreyvelich): Add example here>
• For a major or minor release, 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.
• For a major or minor release, submit a PR against test-infra,
  updating config/jobs/kubernetes-sigs/jobset periodics to drop n - 1 release and add a periodic
  covering the new release branch.
• Close this issue

Changelog

New features

• Add onJobFailureMessagePatterns to distinguish retriable from non retriable Pod failure policies (Add onJobFailureMessagePatterns to distinguish retriable from non retriable Pod failure policies #1033)

Documentation

• Update failure policy KEP: distinguish retriable from non retriable Pod failure policies (Update failure policy KEP: distinguish retriable from non retriable Pod failure policies #1027)

Development and tooling

• use release 0.9 instead of 0.8 in release branch ([main] use release 0.9 instead of 0.8 in release branch #990)
• add test-infra requirement for release (add test-infra requirement for release #991)
• [main] chore(docs): Changelog for JobSet v0.9.0 ([main] chore(docs): Changelog for JobSet v0.9.0 #997)
• use chart version and app version to match kueue tagging (use chart version and app version to match kueue tagging #999)
• write helm package to artifacts (write helm package to artifacts #1003)
• potentially fix date tag on helm push (potentially fix date tag on helm push #1005)
• use hard coded variable for branch name (use hard coded variable for branch name #1008)
• match kueue and jobset cloud build (match kueue and jobset cloud build #1010)
• use 1.34 for envtest and update prod page for 1.34 (use 1.34 for envtest and update prod page for 1.34 #1011)
• Makefile: docker: Add CGO_ENABLED build arg (Makefile: docker: Add CGO_ENABLED build arg to remove a warning message #1023)
• formalize our release process (formalize our release process #1039)

Dependencies

• Bump github.com/open-policy-agent/cert-controller from 0.13.0 to 0.14.0 (Bump github.com/open-policy-agent/cert-controller from 0.13.0 to 0.14.0 #993)
• Bump github.com/onsi/ginkgo/v2 from 2.25.1 to 2.25.2 (Bump github.com/onsi/ginkgo/v2 from 2.25.1 to 2.25.2 #995)
• Bump github.com/stretchr/testify from 1.11.0 to 1.11.1 (Bump github.com/stretchr/testify from 1.11.0 to 1.11.1 #996)
• Bump github.com/prometheus/client_golang from 1.23.0 to 1.23.2 (Bump github.com/prometheus/client_golang from 1.23.0 to 1.23.2 #1014)
• Bump github.com/onsi/ginkgo/v2 from 2.25.2 to 2.25.3 (Bump github.com/onsi/ginkgo/v2 from 2.25.2 to 2.25.3 #1015)
• Bump the kubernetes group with 8 updates (Bump the kubernetes group with 8 updates #1020)

[GiuseppeTT]

All OWNERS must LGTM the release proposal

From #1041, I will assume this is true.

cc @kannon92 @andreyvelich @ahg-g

[GiuseppeTT]

For future reference, these are the complete steps to create a new release branch

git clone https://github.com/kubernetes-sigs/jobset.git
cd jobset
git branch release-0.10 main
git push release-0.10

[GiuseppeTT]

@kannon92 can you do the following steps? 👀

- [ ] After the above PR is merged rebase your local branch and create 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](https://docs.github.com/en/authentication/managing-commit-signature-verification/checking-for-existing-gpg-keys).
- [ ] An OWNER pushes the tag with
      `git push $VERSION`
  - Triggers prow to build and publish a staging container image
      `gcr.io/k8s-staging-jobset/jobset:$VERSION`
- [ ] An OWNER [prepares a draft release](https://github.com/kubernetes-sigs/jobset/releases)
  - [ ] Write the changelog into the draft release.
  - [ ] Run `make artifacts IMAGE_REGISTRY=registry.k8s.io/jobset`
      to generate the artifacts and upload the files in the `artifacts` folder
      to the draft release.

For the tagging part, I believe it can be done with the following

# Clone JobSet
git clone https://github.com/kubernetes-sigs/jobset.git
cd jobset

# Access new release branch
# Rebase can be skipped because it's a brand new clone
git checkout release-0.10
# git pull --rebase origin release-0.10

# Create tag
# This command will open the default text editor to enter the tag description
# See changelog below to copy paste
git tag -s v0.10.0

# Push tag
git push v0.10.0

You can use the following changelog for the tag description

### New features

- Add onJobFailureMessagePatterns to distinguish retriable from non retriable Pod failure policies (#1033)

### Documentation

- Update failure policy KEP: distinguish retriable from non retriable Pod failure policies (#1027)

### Development and tooling

- use release 0.9 instead of 0.8 in release branch (#990)
- add test-infra requirement for release (#991)
- [main] chore(docs): Changelog for JobSet v0.9.0 (#997)
- use chart version and app version to match kueue tagging (#999)
- write helm package to artifacts (#1003)
- potentially fix date tag on helm push (#1005)
- use hard coded variable for branch name (#1008)
- match kueue and jobset cloud build (#1010)
- use 1.34 for envtest and update prod page for 1.34 (#1011)
- Makefile: docker: Add CGO_ENABLED build arg (#1023)
- formalize our release process (#1039)

### Dependencies

- Bump github.com/open-policy-agent/cert-controller from 0.13.0 to 0.14.0 (#993)
- Bump github.com/onsi/ginkgo/v2 from 2.25.1 to 2.25.2 (#995)
- Bump github.com/stretchr/testify from 1.11.0 to 1.11.1 (#996)
- Bump github.com/prometheus/client_golang from 1.23.0 to 1.23.2 (#1014)
- Bump github.com/onsi/ginkgo/v2 from 2.25.2 to 2.25.3 (#1015)
- Bump the kubernetes group with 8 updates (#1020)

[andreyvelich]

For future reference, these are the complete steps to create a new release branch

git clone https://github.com/kubernetes-sigs/jobset.git
cd jobset
git branch release-0.10 main
git push release-0.10

Cool, would you mind creating this as a Makefile instruction, so we can just run make create-release-branch?
WDYT @kannon92 ?

[GiuseppeTT]

Cool, would you mind creating this as a Makefile instruction, so we can just run make create-release-branch? WDYT @kannon92 ?

I like the idea of standardizing the release operations and automating it as much as possible, but for these steps that just use git and don't do any file modification, I think it's better to just improve the release template with the commands

[kannon92]

On it.

[kannon92]

Waiting for https://prow.k8s.io/view/gs/kubernetes-ci-logs/logs/post-jobset-push-images/1971658238659137536.

[kannon92]

opened up kubernetes/test-infra#35602 to add testing on the release branch

[GiuseppeTT]

opened up kubernetes/test-infra#35602 to add testing on the release branch

About that. IMO it makes sense for this step to be one of the first, probably between "For major or minor releases (v$MAJ.$MIN.0), create a new release branch." and "Update BRANCH_NAME in the Makefile and set export VERSION=vX.Y.Z." so that all PRs to the new release branch will have these extra testing enabled. What do you think?

[kannon92]

opened up kubernetes/test-infra#35602 to add testing on the release branch

About that. IMO it makes sense for this step to be one of the first, probably between "For major or minor releases (v$MAJ.$MIN.0), create a new release branch." and "Update BRANCH_NAME in the Makefile and set export VERSION=vX.Y.Z." so that all PRs to the new release branch will have these extra testing enabled. What do you think?

Agree. Ideally once branch is cut we should have CI on it.

[kannon92]

@GiuseppeTT i didn’t get a chance to test the images. Could you open this PR up?

I think you can do the rest of the items. I have a draft of the release ready to publish when the images/charts are ready.

[GiuseppeTT]

@GiuseppeTT i didn’t get a chance to test the images. Could you open this PR up?

I'm happy to do it but I'm not sure what you mean by " test the images" and "open this PR up".

Do you mean debugging the failing test in kubernetes/test-infra#35602?

Or do you mean doing step "Submit a PR against k8s.io, updating k8s.gcr.io/images/k8s-staging-jobset/images.yaml to promote the container images to production:" and the following (verify that the images exist)?