You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since it's inception, MetalK8s adopted a versioning system where the minor is tied to a particular (minor) release of upstream Kubernetes. As an example, MetalK8s 1.0 included Kubernetes 1.10 and the 1.1 versions came with Kubernetes 1.11. Similarly, MetalK8s 2.4 included Kubernetes 1.15, 2.5 Kubernetes 1.16 and so on until the latest MetalK8s 2.10 and 2.11 including respectively Kubernetes 1.21 and 1.22.
This approach is quite simple, and guarantees one gets the same version of Kubernetes when upgrading from one patch release to another, while remaining with the same minor version of MetalK8s.
However, in the spirit of Semantic Versioning, this also comes with a drawback: once a minor version of MetalK8s is released, we can't add any more features in later patch releases, and hence need to wait for a new upstream Kubernetes release leading to a new minor version of MetalK8s which can then bring new functionality to our users.
To alleviate this, we decided to change the MetalK8s versioning approach. Instead of tying a minor version of MetalK8s to a (minor) version of Kubernetes, from now on we push the Kubernetes version into the MetalK8s major. This allows us to add new features to MetalK8s while sticking to a specific version of Kubernetes (by bumping the minor and keeping the major), and to create patch releases when needed.
This also makes sense from a Semantic Versioning perspective: Kubernetes releases can change or drop support for alpha or beta APIs between minor versions, hence, a minor release of Kubernetes could result in what would be a major version bump in semver! With Kubernetes minor versions tied to MetalK8s major versions, we now got this covered.
As before, if you stick to a major version of MetalK8s, we guarantee this will always ship with the same (minor) Kubernetes version.
So, where do we start? MetalK8s 2.11, the current version in development, ships with Kubernetes 1.22. For the Kubernetes 1.23 version, we decided to bump MetalK8s to (hold your breath) 123.0. Then, Kubernetes 1.24 will come in, wait for it... MetalK8s 124.0 (and up), etc.
This removes a long-standing hurdle, holding us back to deliver features to our users without pushing a change in Kubernetes version at the same time. Everybody wins 🚀
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Since it's inception, MetalK8s adopted a versioning system where the minor is tied to a particular (minor) release of upstream Kubernetes. As an example, MetalK8s 1.0 included Kubernetes 1.10 and the 1.1 versions came with Kubernetes 1.11. Similarly, MetalK8s 2.4 included Kubernetes 1.15, 2.5 Kubernetes 1.16 and so on until the latest MetalK8s 2.10 and 2.11 including respectively Kubernetes 1.21 and 1.22.
This approach is quite simple, and guarantees one gets the same version of Kubernetes when upgrading from one patch release to another, while remaining with the same minor version of MetalK8s.
However, in the spirit of Semantic Versioning, this also comes with a drawback: once a minor version of MetalK8s is released, we can't add any more features in later patch releases, and hence need to wait for a new upstream Kubernetes release leading to a new minor version of MetalK8s which can then bring new functionality to our users.
To alleviate this, we decided to change the MetalK8s versioning approach. Instead of tying a minor version of MetalK8s to a (minor) version of Kubernetes, from now on we push the Kubernetes version into the MetalK8s major. This allows us to add new features to MetalK8s while sticking to a specific version of Kubernetes (by bumping the minor and keeping the major), and to create patch releases when needed.
This also makes sense from a Semantic Versioning perspective: Kubernetes releases can change or drop support for alpha or beta APIs between minor versions, hence, a minor release of Kubernetes could result in what would be a major version bump in semver! With Kubernetes minor versions tied to MetalK8s major versions, we now got this covered.
As before, if you stick to a major version of MetalK8s, we guarantee this will always ship with the same (minor) Kubernetes version.
So, where do we start? MetalK8s 2.11, the current version in development, ships with Kubernetes 1.22. For the Kubernetes 1.23 version, we decided to bump MetalK8s to (hold your breath) 123.0. Then, Kubernetes 1.24 will come in, wait for it... MetalK8s 124.0 (and up), etc.
This removes a long-standing hurdle, holding us back to deliver features to our users without pushing a change in Kubernetes version at the same time. Everybody wins 🚀
Beta Was this translation helpful? Give feedback.
All reactions