On Sun, Nov 08, 2020 at 10:49:31PM +0100, Florian Weimer wrote: > * 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>
I can't tell how strict these requirements are in practice. It's similar to Firefox requiring more recent versions of rustc and golang packages are co-installable, so when it comes to that, shipping a new golang-x.y package might also be an option. > Since Go has a bit of spotty history in terms of kernel backwards > compatibility, this could cause further challenges. Do you have a concrete example of such a change? I see that 1.14 is available in backports, so this seems to work out so far. Cheers, Moritz