Deprecating old versions of Cassandra

[emerkle826]

How many combinations of versions of Cassandra, DSE and Managagement API are there?

The answer: A lot

It has come up a few times in the past, but the main questions are:

1. How many versions of Cassandra should we continue to support?
2. When/How should we deprecate older versions of Cassandra?
3. Who/How do we notify users of deprecations?

Current situation

Right now, when a new point release of Cassandra 3.11, 4.0 or 4.1 comes out (or DSE 6.8), we simply add that new version to the build matrix here, here, and/or here and when we tag a new release of Management API, we get all new builds of every version of Cassandra we've ever built, plus the new one we just added.

Soon, we will have Cassandra 5.0 and DSE 7 to add to the matrix. Going forward, we really can't effectively maintain and support an ever growing list.

Possible options

The extreme option (One version per major release)

From a maintenance perspective of just this repository, we could opt to only maintain and support the latest and greatest point release of each major version. At the time of this writing, that would mean we only support Cassandra version 3.11.14, Cassandra 4.0.7 and Cassandra 4.1.0. As soon a s newer release comes out, those versions are excluded and we only build the newest.

The basis for even considering this option is that The base images for Cassandra (maintained by DockerHub) are never rebuilt. Once Cassandra 3.11.X is released, an image is built and it lives in that state forever. There can sometimes be an exception to this if a bug is found in the image, but it is very rare. The usual path forward is to wait fro Cassandra to fix the bug and release a new image based on that.

For DSE, the situation is pretty much the same. Once a version of DSE is released, an image is built and that's it. Bugs found will prompt a new release, and thus a new image with the new version.

Something less extreme (fixed/static number of supported versions)

Supporting only the latest version of Cassandra in Management API probably won't sit well with some, so perhaps we need to come up with a static number of versions we support. Maybe that number is 3 point releases per major release. For example, we have Cassandra 3.11.14, 3.11.13 and 3.11.12 now. When Cassandra 3.11.15 comes out, we stop building 3.11.12.

Something more dynamic (arbitrary deprecation)

Maybe we also decide to deprecate older versions when new features hit Management API that create library dependency conflicts with older versions of Cassandra. See this PR for example.

Who and when do we notify of deprecations?

Clearly, it would be nicer to existing users if they were informed that upgrading to a newer version of Management API will force them to upgrade to a newer version of Cassandra. This probably isn't a big deal to anyone using Management API images directly. It more applies to those using it indirectly through something like cass-operator or k8ssandra-operator.

[burmanm]

My vote goes to support only the newest patch release for new development. Might make an exception for a CVE, but nothing else.

[Miles-Garnsey]

I agree with @emerkle826 and @burmanm, there's no reason we should be supporting old patch releases of Cassandra AFAIK, given there is supposed to be a strong guarantee that patch releases are always non-breaking changes.

However, we do need to consider what this means for our testing processes downstream in cass-operator and k8ssandra-operator. We may want to start doing a find and replace on version strings to ensure we are indeed always testing the latest releases on trunk within that repo.

[adejanovski]

While I agree we should simplify this build matrix and support a limited number of versions, this begs the question of how this will practically impact users.
Let's say we add a new endpoint in the management api, and this endpoint is used by a new version of k8ssandra-operator. It means the new version of k8ssandra-operator becomes incompatible with older versions of the management api.
How do we make it clear for users, before and after the upgrade, that there's an incompatibility, and to which version they should be upgrading? Release notes and Kubernetes events respectively would be my go to.
We will most likely have to pin the minimum version of the management api that is required for each release of k8ssandra-operator (and cass-operator as well), and act accordingly in the code. If we're dealing with an incompatible version, then do we fail fast and push an event to indicate this or do we try to gracefully degrade the functionalities (while still pushing the event/error)?

Also note that the default imagePullPolicy is IfNotPresent, which means that if the 4.0 or 4.0.7 tags are being referenced, they may not be upgraded when the operators get upgraded. How do we deal with this? (maybe this is handled already btw, I'm just not sure how).

[jsanda]

@emerkle826 Can you clarify what exactly is mean by support?

[emerkle826]

@emerkle826 Can you clarify what exactly is mean by support?

Good question.

In the context of this discussion, I meant "support" to be "combinations of Server (Cassandra/DSE) and Management API that we will build upon a new release of Management API". However, "support" probably should also include "images that we maintain and regularly test and verify they work as expected".

My first definition of "support" only places a burden on compute power in GitHub to actually build the images, storage space in DockerHub to store the images, and code maintenance to make sure Management API compiles/runs with new versions of Cassandra/DSE.

The second definition adds a much larger burden to ensure new features/bug fixes in Management API don't break/alter things in old versions of Cassandra (3.11.7 for example) or DSE.