Repository navigation
[RFC] Release Kubernetes Python Clients in parallel for released Kubernetes versions #1242
Description
Activity
The proposal looks good to me. The release branches (release-13.0, release-14.0, release-15.0) have been created.
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?
Reacted by Nabarun PalProposed Timeline (if this proposal is accepted this week)
@palnabarun: it seems progress halted after
17.14.0a1got 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?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/remove-lifecycle stale
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/remove-lifecycle stale
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 StableThe 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.
Reacted by Torgeir L, Thomas Sapelza, Nikunj Rathi and Joshua SleeperThe 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/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas 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
- After 90d of inactivity,
/remove-lifecycle stale
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! 👏
Reacted by Joshua Sleeper and Thomas SapelzaReacted by Felix Hüttner, Nikunj Rathi, Joshua Sleeper and Haowei Cai (Roy)Reacted by Joshua Sleeper/close
@yliaog: Closing this issue.
Details
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.
Need
We are running behind on client releases by quite a margin. The latest Kubernetes client
Proposed Solution
Parallel Alpha releases of the client
release-17.0,release-18.0,release-19.0checking them out of the current state ofmasterbranch where the client is snapshotted to Kubernetes 1.16.Corresponding Kubernetes Releases
masterbranch will be out of sync with the release branch.masterbranch catches up.Problems
masterbranch based on Kubernetes 1.17. The client inmasterbranch now will be in sync with the client generated inrelease-1.17.release-1.17branch, we can cherry-pick them tomasterbranch in the order they were merged to the release branch.masterbranch 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)
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
/assign