* Moritz Mühlenhoff: > * Follow a scheme similar to Firefox ESR where in case of a security > the update either happens to the latest minor release of > the current branch or if that has stopped, happens to the next > major release. To map this to specific k8s releases: Let's assume bullseye > were already stable and would ship 19.3. In three months a security issue > arises which is severe enough to warrant an update and we ship 19.5 > in a DSA. Fast forward 6 months and 19.x is EOLed, but some severe > security issue needs to be fixed; then the bullseye update would move > to 20.1 or so. That sounds unusual for a Debian release, but it's > the status quo for _any_ Kubernetes user after all (whether deployed > on premises or at some "cloud vendor").
Another thing to consider: Kubernetes rebases will likely require Go rebases, if I read this table correctly: <https://github.com/kubernetes/community/blob/master/contributors/devel/development.md#go> Since Go has a bit of spotty history in terms of kernel backwards compatibility, this could cause further challenges.
