Prepare for v0.20

[tomasaschan]

This bumps sigs.k8s.io/controller-runtime to v0.20.x and k8s.io/client-go to v0.32.x according to our release versioning docs.

Next steps after this is merged, is to

• Create a release-v0.20 branch from latest master
• Create a v0.20.0-beta.1 tag
• Start drafting release notes for the v0.20.0 release

@justinsb or @atoato88 Could you, when you have the time, add me as an admin on the repo here on Github, so I gain access to do things like push tags, branches and releases? Currently I don't have that, so I can't really do any of the automated stuff related to releasing new versions.

Closes #421.

[justinsb]

This LGTM other than the test failing.

I sent kubernetes/org#5563 which should be the required permissions.

[tomasaschan]

@justinsb I tried to bump the kubectl version used in the tests, but prow seems to have a cached one (on 1.27, according to logs) which makes the updated API server intereaction expectations invalid.

How do I clear that out?

[justinsb]

Ah, sorry about the kubectl version... I updated it as part of #418. I just cherry-picked it as a standalone PR (#421) also, though I suspect it might rely on #418 because of the switch to use envtest (because I think newer kubectl uses the newer discovery mechanisms, not yet implemented in mock-kubeapiserver).

Direction for mock-kubeapiserver is TBD, I was enthusiastic about it in the past, now I'm feeling that we should focus our efforts on just improving kube-apiserver ... much harder, but a much bigger payoff (envtest uses "real" kube-apiserver.)

[tomasaschan]

Sequencing of all of this is a bit unclear to me. Are you suggesting we do #421 before tagging a new version? Or after?

[justinsb]

Sequencing of all of this is a bit unclear to me. Are you suggesting we do #421 before tagging a new version? Or after?

So in theory we can do it all at once now. Because this PR updates TAG_VERSION, it should get tagged with that version after merge. Because the version is beta.1 we will also create a new release branch at that point.

I guess in general therefore that we should update kubectl alongside the TAG_VERSION to beta.1 (although maybe we a minor lag or two?)

We haven't been fully disciplined about this previously, so I think we will likely have some PRs that would ideally be smaller while we figure this out. e.g. maybe we bump kubectl during the alpha (before cutting a branch,) but really that only works if we had a previous release branch.

This LGTM, as long as we can get the tests to pass. And seeing as they are I am going to lgtm (after I check whether TAG_VERSION expects a v prefix or not)!

[tomasaschan]

This LGTM, as long as we can get the tests to pass.

Tests passed locally when I had [email protected], so I'm pretty confident they will pass now - at least assuming this was enough to make the test runner also use that version :)

[tomasaschan]

💥

[justinsb]

Awesome, thank you @tomasaschan

/approve
/lgtm

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: justinsb, tomasaschan

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [justinsb,tomasaschan]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[justinsb]

And we have a new tag and a new branch 🎉

[tomasaschan]

🎉

I suppose that means any changes we want to get into v0.20 need to get cherry-picked after merging to master. Do we do that manually, or is there tooling support for that too?

[justinsb]

I suppose that means any changes we want to get into v0.20 need to get cherry-picked after merging to master. Do we do that manually, or is there tooling support for that too?

Correct & yes it's manual (ish). In kOps we have this document which describes how to use the k/k tooling...

https://github.com/kubernetes/kops/blob/f5f48d37716071dd2c5e1f6f9530f588dba7e2ab/docs/contributing/proposing-a-cherry-pick.md?plain=1#L5

Maybe we try that as a starting point? I find the script quite hard to use because it assumes different defaults, but it's a good place to start.

[tomasaschan]

Tried to skim that script to see what it does, but it's pretty involved. IIUC, a manual (and less formal) process that mimics the important parts (?) of the k/k way of doing things:

1. Check out a new branch locally based on the target release branch
2. Cherry-pick the relevant commit(s)
3. Open a PR targeting the release branch

Can that PR be merged using our normal tooling (/approve + /lgtm and then the bot merges) or do we do that manually using the github tooling since it's not targeting the default branch? (I don't have access to branch settings etc yet, so can't look at what branch protection rules etc are set up...)