Replies: 3 comments 1 reply
-
Here's what's due to be removed in v1.22: https://kubernetes.io/docs/reference/using-api/deprecation-guide/#v1-22 There's plenty going on. RBAC resources, CustomResourceDefinitions. Now I've thought about it I'm in favor of writing up the 100,000' view. I'd be happy to help write the Ingress part of that article. |
Beta Was this translation helpful? Give feedback.
-
I think that sounds like a great idea. Let me know if there is anything I can do to help make that happen. |
Beta Was this translation helpful? Give feedback.
-
Here's a couple of things discussed in the last SIG-Docs meeting: @PI-Victor: Blog article about deprecation might clash with release notes (“No, really, you must read this before you upgrade”) e.g.: https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.22.md#urgent-upgrade-notes @sftim: Can we try to use identical wording in both places? (note @PI-Victor: both the release notes and the deprecation blog) @chrisnegus: Common / clear terminology will really help. (note @PI-Victor: what is the correct way to underline that a feature has been deprecated (still available but not removed) and that a feature has been physically removed from the code. (@PI-Victor ): “Deprecated and removed” - it's what i usually find in general when a feature is no longer in the code. @shannonxtreme: Explain differences in style guide and recommend consistent terms to use. Please add your own if i've missed anything, sorry for the extra gh notification. |
Beta Was this translation helpful? Give feedback.
-
The purpose of this discussion is to bring a few different threads from Slack and existing issues together for us to talk through how the project can improve communication of API feature deprecations and removals. We have a more immediate decision to make for the 1.22 cycle, ideally we can leverage this discussion to make decisions moving forward as well.
I had proposed during an earlier community meeting that we add to the organization of a release-specific deprecations blog to the Comms deliverables, for each release. This echoes prior proposals in an existing issue opened during the 1.20 cycle.
That issue calls out some other issues to address around ownership and mechanisms.
kubernetes/community#5344 (comment)
kubernetes/community#5344 (comment)
kubernetes/community#5344 (comment)
Let's use this discussion to pick up from the most recent comment from @divya-mohan0209.
To synthesize the threads and comments, I'd like to propose we add a standing deliverable to the comms team to organize a deprecations and removal blog for each release. This article would provide a one-stop for new deprecations as well as features no longer served in the new release. This article can be as long or as brief as is appropriate for the release, and can link out to specific deeper-dive articles on more complex issues (which will also need to be organized and managed on the comms calendar). It should be timed sometime after code freeze, but well enough ahead of the release that it gives the community some time to plan.
It's been observed by more than a few that Vallery's deprecations blog from 1.16 is a fantastic example to work from.
To the immediate decision on how best to communication deprecations and removals for 1.22, @sftim has suggested a generic blog article about Ingress deprecation in this issue. This is a good opportunity to look at all deprecations and removals and determine if the bulk of such an article would be the Ingress topic, or if there's enough to have a 100k-foot view blog which links to an Ingress article.
What are folks' thoughts on this?
Beta Was this translation helpful? Give feedback.
All reactions