Releasing Kubernetes faster

[justaugustus]

During the discussion about modifying the Kubernetes release cadence, a few commenters mentioned releasing Kubernetes faster as a potential option.

While this is not currently planned, I'm copying over some key comments to encourage folks to continue the discussion and to hopefully distill some longterm opportunities for improvement:

@sebgoa:

IMHO with more releases, developers don't need to rush their features, upgrades a more bite size and it necessarily pushes for even more automation.

So at the risk of being down voted I would argue that we have worked over the last 15 years to agree that "release early, release often" was a good idea, that creating a tight feedback loop with devs, testers and users was a very good idea.

Theoretically we should have processes in place to be able to automatically upgrade and be able to handle even a higher cadence of releases. I could see a future were people don't upgrade that often because there are less releases and then start to fall behind one year, then two...etc.

@johnbelamaric:

I could see a future were people don't upgrade that often because there are less releases and then start to fall behind one year, then two...etc.

Yes, this is a big fear of mine as well. We have worked hard to prevent vendor-based fragmentation (e.g., with conformance) and version-based fragmentation (with API round trip policies, etc). Bigger releases with riskier upgrades may undermine that work. We must avoid a Python2 -> 3 situation. This is also why we elected for a longer support cycle as opposed to an LTS. With the extensive ecosystem we have, fragmentation is extremely dangerous.

I don't think going from 4->3 releases will create this problem, though I do think going to 2 or 1 release would. We need some plan around the mitigations I described earlier though, to ensure we avoid this fate.

@sftim:

If there were an unsupported-but-tested Kubernetes release cut and published once a week - what would that mean?

I'm imagining something that passes the conformance tests (little point otherwise) but comes with no guarantee. The Rust project has a model a bit like this with a daily unstable release which has nevertheless been through lots of automated testing.

When I'm typing this I'm imagining that I could run minikube start --weekly-unstable and get a local test cluster based on the most recent release. If Kubernetes already had that built and working, would people pick different answers?

@jberkus:

@sftim yeah, you've noticed that the reason, right now, we don't see a lot of community testing on alphas and betas is that we don't make them easy to consume.

I'd say that it would need to go beyond that: we'd need images, minikube, and kubeadm releases for each weekly release.

I don't know how that would affect our choice of major release cadence (isn't it orthagonal?) but it would be a great thing to do regardless. Also very hard.

cc: @kubernetes/release-engineering

[jberkus]

So, I'm confused, weren't we just clearing a path for 3 releases a year? What changed?

[justaugustus]

@jberkus -- Our current planned path forward is three releases a year, so nothing has changed. The KEP is now up here: kubernetes/enhancements#2567

This topic was opened to give people an opportunity to kick around ideas for future improvements, while recognizing that faster releases are out-of-scope for the current proposal.