# LTS

## What is it?

- A long lived stable branch with associated testing and release infrastructure
- Releases are infrequent
- Releases have to be secure (CVE's)
- Ability for folks to move from a non-LTS release to an LTS release
- Ability for folks to move from LTS release to another LTS release
- Need to keep cutting point releases for bugs/backports/security off this branch
- new point releases MUST be fully backward compatible with the previous point releases
- [stricter policy than the kubernetes policy](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-release/cherry-picks.md#what-kind-of-prs-are-good-for-cherry-picks) on backports/cherry-picks
- Clear Policy on when an older LTS is sunset. Forced upgrades to new LTS with no exceptions
- No Beta API(s) of any kind

## Costs

- All CI jobs associated with the stable branch must keep functioning
- Exact release infrastructure must continue to work
- CVE(s) will need to be patched, in the code, in the ci/release infra
- Backports will need domain expertise, we will need people who are intimately familiar with the SIG's work and know exactly what needs to be ported back and how to make sure tests are backported as well to LTS when some code is backported
- Flakes will be a concern, so we will need to invest in fixing flakes in upstream first and then backport changes to LTS
- Folks taking care of testing/release MUST learn the work being done in upstream so they can replicate the same in downstream
- No short-cuts, we cannot test in production (in customers clusters), we have to be very thorough, even more than what we do under normal circumstances
- We'll need well-defined skip upgrade paths between non-LTS -> LTS as well as LTS -> LTS

## Notes

- Similar to maintain a fork of a project, but fully funded
- We'll need a dedicated set of folks fully follow upstream work (and help in upstream work), so when they need to backport something, they know what they are doing (FOR ALL SIGS)
- We'll need a dedicated testing/release folks who similarly participate in upstream who can then help in the downstream work.
- Note this includes by definition not just Kubernetes but also associated things like golang, coredns, etcd and so on.

## Wish / Thoughts

- We should go do this and then show the community and other vendors how we do this
- We should do this in the open
- We should charge customers for using LTS and this revenue stream can fund the dedicated team(s) required
- There are people who do this for other vendors in the community, we can have a loosely-coupled/federated bi-weekly sync to share what we are doing and invite collaboration

## Discussion at kubecon community unconference

https://docs.google.com/document/d/1C7utWMjGpDcBc5TB_ooddERsid59sFLC7gqLzyS5aKY/edit