Kubernetes moves to end ‘permanent beta’ for some APIs
(2020/08/28)
- Reference: 1598602809
- News link: https://www.theregister.co.uk/2020/08/28/kubernetes_1_19/
- Source link:
The Kubernetes project has decided the time has come to stop existing in a state of permanent beta.
The decision, [1]included in the Changelog for version 1.19 of the container-wrangling code and [2]explained in a blog post, reflects the fact that Kubernetes offers plenty of REST APIs and they can evolve … or not.
The project’s new rules mean that when a new feature's API reaches beta, a nine-month countdown commences. Within that timeframe, the beta must either reach general availability (which deprecates the beta) or start anew (which deprecates the previous beta).
“The motivation here seems pretty clear: get features stable,” wrote Kubernetes contributor Tim Bannister of The Scale Factory. “Guaranteeing that beta features will be deprecated adds a pretty big incentive so that people who want the feature continue their effort until the code, documentation and tests are ready for this feature to graduate to stable, backed by several Kubernetes' releases of evidence in real-world use.”
Another version 1.19 feature introduces warnings of deprecated APIs.
The new release also extends bugfix support via patch releases for a Kubernetes minor release has from nine months to a full year.
“A survey conducted in early 2019 by the working group (WG) Long Term Support (LTS) showed that a significant subset of Kubernetes end-users fail to upgrade within the previous nine-month support period,” says the version 1.19 Changelog. “A yearly support period provides the cushion end-users appear to desire, and is more in harmony with familiar annual planning cycles.”
An Alpha feature adds storage capacity tracking, a welcome addition given that the Kubernetes scheduler currently assumes infinite storage capacity in a cluster. Previous fixes partially fixed that situation but the system still had no way of knowing if sufficient storage would be available for new pods.
“This feature serves as a stepping stone for supporting dynamic provisioning for local volumes and other volume types that are more capacity constrained,” the changelog says. ®
Get our [3]Tech Resources
[1] https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.19.md#what%E2%80%99s-new-major-themes
[2] https://kubernetes.io/blog/2020/08/21/moving-forward-from-beta/
[3] https://whitepapers.theregister.com/
The decision, [1]included in the Changelog for version 1.19 of the container-wrangling code and [2]explained in a blog post, reflects the fact that Kubernetes offers plenty of REST APIs and they can evolve … or not.
The project’s new rules mean that when a new feature's API reaches beta, a nine-month countdown commences. Within that timeframe, the beta must either reach general availability (which deprecates the beta) or start anew (which deprecates the previous beta).
“The motivation here seems pretty clear: get features stable,” wrote Kubernetes contributor Tim Bannister of The Scale Factory. “Guaranteeing that beta features will be deprecated adds a pretty big incentive so that people who want the feature continue their effort until the code, documentation and tests are ready for this feature to graduate to stable, backed by several Kubernetes' releases of evidence in real-world use.”
Another version 1.19 feature introduces warnings of deprecated APIs.
The new release also extends bugfix support via patch releases for a Kubernetes minor release has from nine months to a full year.
“A survey conducted in early 2019 by the working group (WG) Long Term Support (LTS) showed that a significant subset of Kubernetes end-users fail to upgrade within the previous nine-month support period,” says the version 1.19 Changelog. “A yearly support period provides the cushion end-users appear to desire, and is more in harmony with familiar annual planning cycles.”
An Alpha feature adds storage capacity tracking, a welcome addition given that the Kubernetes scheduler currently assumes infinite storage capacity in a cluster. Previous fixes partially fixed that situation but the system still had no way of knowing if sufficient storage would be available for new pods.
“This feature serves as a stepping stone for supporting dynamic provisioning for local volumes and other volume types that are more capacity constrained,” the changelog says. ®
Get our [3]Tech Resources
[1] https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.19.md#what%E2%80%99s-new-major-themes
[2] https://kubernetes.io/blog/2020/08/21/moving-forward-from-beta/
[3] https://whitepapers.theregister.com/
"to help slow upgraders"
Mike 137
So "upgrading" is now an obligation that some folks "shirk"? I thought IT was tools for running businesses, but it appears that's only part of its function. The other (and possibly greater) part seems to be to keep vendors' income streams flowing.
We have a mechanical workshop where some of the tools are almost 50 years old. They're still in use because:
[a] the makers got them right in the first place
[b] they still work
If both those criteria were applied to IT, most users would be much happier and much safer.
That's a good thing
I totally agree with this position. Way too many projects end up gathering dust on the shelves after the initial feature set is more or less working.
This will at least level the field - either someone is actively taking care of the project, or the project dies the death that is waiting for it.