Deprecation policy

Contributors' corner
1

We need to determine what versions of of Cassandra and k8s we will support and when we will deprecate support. We would like to obtain input from the community to ensure that we are not leaving anyone behind prematurely.

Note that support is what is under discussion, not availability. We intend that all built images will remain available, and, as a reminder, we are an open source project and the full history of the project remains available in Git for those who wish to build from source.

What we are addressing is whether new versions of k8ssandra will be guaranteed compatible with older versions of k8s and Cassandra. For example, when we release K8ssandra 1.4, what is the oldest version of Cassandra and Kubernetes that we should have tests for?

My proposals follow:

Cassandra

  • We should support the latest patch version for the latest minor version, and the two latest major versions.
  • As of now, this means we would support 3.11.11, 4.0.0.
  • Once 4.1 is released, versions of k8ssandra released after 4.1 (for example, 1.4) deprecate support of 4.0.
  • The next K8ssandra minor version release (1.5) would then remove support entirely (although things may continue to work, we would stop testing against 4.0 and would no longer fix bugs).

K8s

  • We support k8s versions under support from the k8s project. This means that sometimes a k8s version may only be supported for as little as 12 months.
  • We will trigger deprecation when a version is 3 minor versions behind latest, and remove support of versions 4 minor versions behind latest. This means if you tried to run K8ssandra under 1.19 as of now, you’d receive deprecation warnings.
  • At present, we would support k8s 1.19 - 1.22, but we would plan to drop support of k8s 1.19 in K8ssandra 1.14.
  • We should have full test coverage for all supported versions.

I would like to invoke lazy consensus with the 72 hour window for comment commencing now.

1 Like
2

I’m a huge +1. I support the idea of deprecating versions to announce to users the intention so there’s time for them to prepare for the idea.

This should trigger some extra documentation targetted at new Kubernetes users who may not necessarily understand the nuances and what it means for them.

We (the community) should also do more around making it clear that K8ssandra is our opinionated view of how to run/operate/manage Cassandra clusters. :beers:

1 Like
3

w.r.t. the question about K8s version support, we have previously followed a path charted by the major cloud providers, with an assumption that that will be the primary way that K8ssandra is deployed. While they have a bit of variation to what they support through different “channels” or whatever one provider might call it, we’ve tried to provide as much coverage for that as possible.

If we continue that, I think we’d likely be a bit broader than the directly supported version by the K8s project itself.

1 Like
4

@jdonenine ^^ sounds good. I laboured over whether we should actually support the most recent k8s version tbh, because the cloud providers usually take a while to release it (at least they used to when I was using them heavily).

I wonder if we shouldn’t actually shift it backwards so that we support versions latest-1 to latest-4 with deprecations for latest-5 and older? Open to further discussion there. I do think we need to figure out a way to only support 3-4 versions one way or another just to keep things manageable.

5

In several fields, deprecation is the discouragement of use of some terminology, feature, design, or practice , typically because it has been superseded or is no longer considered efficient or safe, without completely removing it or prohibiting its use.