Proposed Changes to Patch Release Process

[jeremyrickard]

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 candidate images 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. We can still create the tag, and would like to discuss the implications of those changes more below.

We would not incorporate this change before the January patch releases, so please provide feedback below so we can properly evaluate this change.

[jeremyrickard]

From @BenTheElder's email feedback

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

[jeremyrickard]

From @liggitt 1 2

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?

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.

[jeremyrickard]

From @saschagrunert 1 2

[1]
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

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

I gave it a test run with the PR:
kubernetes/release#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

[xmudrii]

we do not publish release candidate images for the subsequent patch releases.

I think that we should also stop publishing artifacts, i.e. binaries as well. Moreover, I think that's what kubernetes/release#2765 is doing as well. That could give us a huge performance improvement to the release process.

[saschagrunert]

I think we should have a full set of artifacts available for each tag for consistency reasons. Right now we don't publish packages for pre-releases, but I think they should be available as well. Therefore I'd prefer to drop the additional RC completely.