Proposed Changes to Patch Release Process

[Jeremy Rickard]

Hello Kubernetes Community,

We would like to propose a small change to our patch release process. Today, when we publish a patch release, such as v1.25.4, we also publish a release candidate (rc) for the next version, such as v1.25.5-rc.0. This requires two sets of image promotions, which extends the time for each patch release. We would like to propose that for future patch releases, we *do not* publish release candidates for the subsequent patch releases. This will decrease the time required for each patch release and will eliminate potentially unused images from the community infrastructure. 

Before making this change, we wanted to solicit feedback from the community to determine if anyone is using these images. 

We currently plan on releasing the next set of patch releases on December 8th. We would like to request any feedback on this change prior to December 2nd so that we can incorporate the change into that set of patch releases, absent any negative feedback from the community. 

Thank you!

Jeremy Rickard // on behalf of SIG Release

[Jordan Liggitt]

Would an .rc.0 tag still be added to the branch to clearly delineate any subsequent builds as containing unreleased content, or would the rc tag be dropped as well?

--
You received this message because you are subscribed to the Google Groups "dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev+uns...@kubernetes.io.
To view this discussion on the web visit https://groups.google.com/a/kubernetes.io/d/msgid/dev/CAEHNk2wrRfWac%3DP%3DrGDDXh61bNv7iZsX_MCoh7wznjhOsiNzzQ%40mail.gmail.com.

[Sascha Grunert]

Hey Jordan,

Technically we do not have any unreleased content between, say v1.25.4
and v1.25.5-rc.0:

2022-11-09 13:28 +0000 Kubernetes Release Robot ∙ <v1.25.5-rc.0>
Release commit for Kubernetes v1.25.5-rc.0
2022-11-09 13:28 +0000 Kubernetes Release Robot ∙ <v1.25.4>
Release commit for Kubernetes v1.25.4

So I'd prefer to remove the tag v1.25.5-rc.0 as well. This also means
that we're getting closer to releasing everything we tagged, because
we do not create deb/rpm packages for pre-releases.

All the best,
Sascha

> To view this discussion on the web visit https://groups.google.com/a/kubernetes.io/d/msgid/dev/CAMBP-pKivagECoMAFj3mGidY2H%2Bwm02ndUW0WQmS%3DHBtO5kWJw%40mail.gmail.com.

[Jordan Liggitt]

That has the side effect of making builds at HEAD of release branches be a variant of the last-released patch version tag, instead of the upcoming patch version:

• With the rc tag, HEAD of upstream/release-1.25 is v1.25.5-rc.0-1-g21e06572c3b
• Without the rc tag, HEAD of upstream/release-1.25 is v1.25.4-2-g21e06572c3b, which is less clearly a prerelease build of v1.25.5

That may be worth the saved build time, I just wanted to make sure that side effect was known/considered.

[Benjamin Elder]

We should check the impact on the version libraries, Kubernetes tools (like KIND, my personal experience) compare versions to determine if features are available.

E.G. the logic in:
https://pkg.go.dev/k8s.io/apimachinery/pkg/version
https://pkg.go.dev/k8s.io/apimac...@v0.25.4/pkg/util/version

To view this discussion on the web visit https://groups.google.com/a/kubernetes.io/d/msgid/dev/CAMBP-pJ8xgK12JGmEF2TPyCQKBA4fPzrmoEdTcNWA0M4F4SN_Q%40mail.gmail.com.

[Sascha Grunert]

Yes, so the build version would be different as already mentioned.

I gave it a test run with the PR:
https://github.com/kubernetes/release/pull/2765
krel stage takes now 1h from previous 2h
krel release takes now 9min from previous 13min

The changelog generation looks good and the tags are as expected in
the staged sources.

All the best,
Sascha

[Jeremy Rickard]

Thank you everyone, for the feedback so far. 

At the SIG Release meeting yesterday, we decided that we should move this to a GH discussion to better record the feedback and so we can convert this to an issue for tracking once we're ready to move forward. 

You can find that discussion here: https://github.com/kubernetes/sig-release/discussions/2090

I will summarize the feedback so far from this email thread in that discussion and tag folks. 

We also decided to NOT make any changes for the December patch releases. So this will happen no earlier than January. 

Thanks again for the feedback and please continue on the GH discussion.

[Benjamin Elder]

Yes, the build version is of course different, but does it have comparable comparison / sort behavior in these packages?

I would assume so, but if not, that might be one of the few things that would actually break, so it would be better to confirm.