We've talked alot lately about recent releases (or even lack there of). We are well aware of this issue and talk about it during just about every office hour. I'd like to figure out a way for us to better expose what's happening.
To be clear, we cut final Kops releases when we consider them _production ready_. We encourage you to test our alphas and betas, and to provide feedback on new versions of Kubernetes via issues and PRs. That being said, we haven't kept up our side of the deal... we need an easy way to summarize the current release status and provide our users with as much info as we can on the status of upcoming releases.
Since currently kops 1.11 is blocked by a Kubernetes patch that is not in k/kops, I'd like to propose we raise awareness somewhere in our github repo more effectively (which I hope to discuss here).
Options:
- More strictly follow and update Milestones
- Create a centralized one stop source of release status: could be a file somewhere like
docs/release_status.mdwith the latest PRed update on our releases.
Other ideas are welcome but I think there could be real value to a status page or updated release note for now until we figure out the best location. I'm happy to write and own a status page based on summaries of meetings and chats however I wanted to see other's thoughts prior to opening a PR.
Thanks!
mikesplain
All 16 comments
I think either way it's a good idea to follow/update milestones; it helps people get a general idea of how far the work on the update is, and also allows contributors wanting to help get an update over the finish line to quickly see what they can help with.
A doc would probably be a good option especially for cases like this (waiting for a Kubernetes patch). Just gotta make sure it stays up-to-date (the one problem with documentation; it's out of date as soon as you write it).
dzoeteman
on 14 Dec 2018
I think one thing that would help people deal with the slow release is to have concurrent releases for stable, beta, and alpha.
I've been wanting to expand upon the concept of channels in the codebase for a long time, and I think this would help a lot with the communication problem as well because it will take the pressure off of doing a production-ready release, and the testing & alpha releases can happen much more frequently.
The issues preventing this mainly are around the release process being cumbersome and bottlenecked on @justinsb, or at least it used to be, it's been a while since I looked into it.
blakebarnett
on 14 Dec 2018
A single doc that states the status of the upcoming release would be a great start, especially in cases like the present where the release is blocked by something upstream.
joshbranham
on 14 Dec 2018
A status doc would be great, RELEASE_STATUS.md would make life simpler
ms4720
on 14 Dec 2018
As a user of kops with multiple clusters, running with @blakebarnett's idea of alpha/beta/stable release channels sounds super great to me. I can test alpha/beta releases in my sandbox/staging environments and if I really, really need the features in those channels before a stable release is cut with them then I can choose to push that to production.
willnewby
on 14 Dec 2018
@mikesplain What is blocking the release of 1.11 ?
Patafix
on 18 Dec 2018
@Patafix, according to the #kops-dev Slack channel, it's https://github.com/kubernetes/kubernetes/pull/70154
geekofalltrades
on 18 Dec 2018
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-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale
fejta-bot
on 18 Mar 2019
Issues go stale after 90d of inactivity.
That's really disheartening. Kubernetes 1.14 is in beta rc; 1.11 is about to be out of support.
geekofalltrades
on 19 Mar 2019
are there any alpha or beta releases for kops 1.12 and later?
ms4720
on 19 Mar 2019
1.14 is released
drewwells
on 26 Mar 2019
Is there any update on this?
dictvm
on 27 Mar 2019
rifelpet
on 27 Mar 2019
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
fejta-bot
on 26 Apr 2019
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close
fejta-bot
on 26 May 2019
@fejta-bot: Closing this issue.
In response to this:
Rotten issues close after 30d of inactivity.
Reopen the issue with/reopen.
Mark the issue as fresh with/remove-lifecycle rotten.Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/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.
k8s-ci-robot
on 26 May 2019
Related issues
chrislovecnm
路
3Comments
endejoli
路
4Comments
joshbranham
路
3Comments
thejsj
路
4Comments
argusua
路
5Comments
Most helpful comment
I think either way it's a good idea to follow/update milestones; it helps people get a general idea of how far the work on the update is, and also allows contributors wanting to help get an update over the finish line to quickly see what they can help with.
A doc would probably be a good option especially for cases like this (waiting for a Kubernetes patch). Just gotta make sure it stays up-to-date (the one problem with documentation; it's out of date as soon as you write it).