[RFC] Release Kubernetes Python Clients in parallel for released Kubernetes versions

[palnabarun]

Need

We are running behind on client releases by quite a margin. The latest Kubernetes client

Proposed Solution

Parallel Alpha releases of the client

• Create the release branches release-17.0, release-18.0, release-19.0 checking them out of the current state of master branch where the client is snapshotted to Kubernetes 1.16.

Corresponding Kubernetes Releases

Client	Kubernetes
17.0.0	1.17
18.0.0	1.18
19.0.0	1.19

• Generate Alpha client in each of the branches changing the upstream version corresponding to each release.
• Release the Kubernetes Client Alpha version.
• Any bug fixes need to be merged to the release branch itself since the generated client on the master branch will be out of sync with the release branch.
• The Beta and Stable releases can be done as client on master branch catches up.

Changes to python-base can still be merged to master branch since they are supposed to be generic tooling and should ideally work with any Kubernetes version.

Problems

• The bug fixes have to be merged to the corresponding release branches.
• Masters snapshot would considerably be out of sync with the release branches. To mitigate this we can do the following:
  • Let's say Kubernetes Client 12.0.0 stable (based on Kubernetes 1.16) gets released.
  • After that, we will snapshot the master branch based on Kubernetes 1.17. The client in master branch now will be in sync with the client generated in release-1.17.
  • As for bug fixes made to release-1.17 branch, we can cherry-pick them to master branch in the order they were merged to the release branch.
  • This way gradually master branch would catch-up to the release branch.

Release Cadence

To catch up to the releases, we can set a release cadence until we catch up. For example, let's say every 2 weeks we will try to release a new client version until we catch up.

Proposed Timeline (if this proposal is accepted this week)

Date	Client Version Released/Master Snapshot	Release PRs (if done)
2020-09-09	12.0.0b1 (doesn't depend on this proposal)	#1235
2020-10-12	12.0.0 Stable (doesn't depend on this proposal)	#1280
The client takes a jump in version number. See this for more information.
2020-11-13	17.0.0-snapshot (master snapshot)	#1307
2020-11-14	17.14.0a1	#1317
2020-11-24	18.0.0-snapshot (master snapshot)	#1319
2021-12-21	19.0.0-snapshot (master snapshot)	#1320
2021-04-23	18.0.0a1	#1411
2021-05-03	17.17.0b1	#1449
2021-05-13	17.10.0 Stable	#1464
2021-06-22	18.20.0b1	#1496
2021-08-17	18.20.0 Stable	#1520
2021-09-20	19.15.0a1	#1552
2021-10-11	19.15.0b1	#1569
2021-09-14	19.15.0 Stable	#1584
2021-09-28	20.0.0-snapshot (master snapshot)	TBD
2021-09-29	20.Y.0a1	TBD
2021-10-06	20.Y.0b1	TBD
2021-10-07	20.Y.0 Stable	TBD
2021-10-21	21.0.0-snapshot (master snapshot)	TBD
2021-10-22	21.Y.0a1	TBD
2021-10-29	21.Y.0b1	TBD
2021-11-05	21.Y.0 Stable	TBD
2021-11-19	22.0.0-snapshot (master snapshot)	TBD
2021-11-20	22.Y.0a1	TBD
2021-11-27	22.Y.0b1	TBD
2021-12-07	22.Y.0 Stable	TBD

With the above schedule, we will just be able to catch up to the Kubernetes releases. The next Kubernetes version (1.23) will tentatively release on 7th December.

Updates

• Updated the timeline according to the latest information
• Updated the client release versions according to the latest versioning changes ([RFC] Syncing Kubernetes Client versions with upstream Kubernetes versions #1244)

/assign

[roycaihw]

The proposal looks good to me. The release branches (release-13.0, release-14.0, release-15.0) have been created.

[LevonTostig]

Could you update the table under Release Cadence? From what I can gather...

13 November | 17.14.a1 | #1317

Would it also be possible to update the dates in the column Date to not state dates in the past for future releases?

[torgeirl]

Proposed Timeline (if this proposal is accepted this week)

@palnabarun: it seems progress halted after 17.14.0a1 got released in November, about four weeks behind the proposed timeline. Did the alpha reveal a showstopper, or are there issues beyond this project that have lead to the new delay?

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[torgeirl]

/remove-lifecycle stale

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[torgeirl]

/remove-lifecycle stale

[palnabarun]

Updates on this effort: Due to limited bandwidth and technical constraints, we have scrapped the plan to parallelly snapshot different releases.

What we are going to do now is:

X-1.Y.0 Stable Release <---- 2 weeks ----> X.Y.0 Snapshot and Alpha <----- 1 week ----> X.Y.0 Beta <----- 1 week ----> X.Y.0 Stable

The reason that we are spacing Stable and snapshots 2 weeks and the other cuts 1 week is because most people don't try out the alpha or beta versions and encounter bugs directly with the stable version. So, we are increasing the pace of pre-releases but reducing the pace between a stable release and the next pre-release.

I have updated the schedule table above with an updated proposed timeline.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[torgeirl]

/remove-lifecycle stale

[torgeirl]

With Monday's 23.x release the Python client have finally caught up the platform, and I guess this issue therefore can be resolved now.

Thanks to @yliaog and the rest of the team for your hard work! 👏

[yliaog]

/close

[k8s-ci-robot]

@yliaog: Closing this issue.

In response to this:

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.