I find it odd to reply to a github thread, but I’m happy to if you all feel the feedback would be better there. Formally, I used to work for Linux Distribution company that built a Kubernetes Distribution. Kubernetes should not create a LTS release.
I often find those asking for an LTS are either one of two kinds of people. Either those that are building bespoke Kubernetes clusters by hand or a company building a distribution.
The former is fine, but that’s the trade off to not using a distribution. So if you want an LTS of Kubernetes it’s plausibly because you want to prevent having to churn and test a bespoke deployment every quarter.
The latter are simply because building and testing distributions are hard (I led an engineering team doing just that), having upstream put a stake in the ground saying this is a long term support version shifts the burden of back-porting patches and maintenance from their distro team to the upstream.
Kubernetes is rolling fast and I know that’s a bit of a meme about Kubernetes but it’s true. To sink into an LTS cycle is a huge overhead in coordination to support releases longer than already are. Honestly, the current model of what appears to be N+2 versions supported means you have nearly a year of support for whatever version you start with. In a project which releases 4 minor releases a year that’s a decent buffer. If a distribution wants to claim they have an LTS Kubernetes, that’s fine. However, that’s simply their decision and they would need to field the work to do that.
In all honesty, having seen the work it takes to support an LTS distribution I wouldn’t want to wish that on a community like this, especially given it’s unique challenges coordinating large swaths of code in a purely community aspect.