Discussion: Officially supported version ranges

[santi]

I think we should have a larger discussion in this repo on what we actually want to support in custom container setups, as making the implementation support all versions since the beginning of time will lead to a lot of nasty workarounds while only catering to a (presumably) small portion of people that want to use legacy versions.

There has already been some discussion happening here and here.

We need to ask ourselves the following question, and probably a lot more:

• Should we support the latest version?
• Should we only support officially supported versions of the service?
• What repositories should we support? What if there are changes between the images in the different repositories?
• If there is no officially supported version range, what do we do?

Having support for an explicit version range would also require us to cap the support on the latest release, and check / update the version range on every new release (otherwise we cannot know if the new versions are actually compatible or not, and it would be worse to say incorrectly that we support something than not supporting it).

My personal take on this is that in order to reduce the amount of extra / duplicated / workarounds in code to support multiple version ranges, we should be quite restrictive on what versions we do officially support. E.g. for ElasticSearch we could support the official versions ^8.8.1+ and ^7.17.10 (found here), but nothing more. For images like Keycloak we should be even more restrictive in our officially supported version ranges, as it is very lacking in documentation on what actually is maintained, lots of breaking changes between versions etc., and only support the latest major version (v22.x as of writing)

Supporting latest is a bad idea, as we can see from the tests as bad images are published quite frequently before getting a quick/hotfix immediately after. At the very least, no tests should use latest for testing, as it destroys the reproducibility.

What do you guys think?

[TheForgottened]

I'll leave my 2 cents here, mostly based on my experience with the Keycloak image (since that's what I worked on).

On versions / tags

We should aim to support the whole image range (within reason) as long as it isn't too much of a hassle. Worst case scenario we should support at least the currently running LTS (or similar).

When there's no official LTS or alike and every new version has a chance of breaking, e.g. Keycloak, we should try to at least maintain the latest, but again, if possible, maintain the whole range. I know the code on my PR isn't the most pretty around there, but seems to work for all the images available. Maybe we can also find this kind of not-so-pretty but also not-so-bad workarounds for other images like the Keycloak's.

Based on my particular use case, I turned into testcontainers to write tests to a legacy infrastructure that's getting updated, meaning I need support for both old and legacy versions of the image and the most recent ones.

This means I can write tests with an image based on the current running version, and then just change the version to check if everything will fit nicely.

On latest / nightly tags (or equivalent)

Although I understand your point, I believe it's actually not a bad thing.

Our tests break with the latest version of an image? Great! Now we know we need to update our code in order to provide proper support again.

I believe this is important because, again, thinking about my use case, people will turn to these testcontainers to test if infrastructure changes (like updates) will have any kind of impact in the code they're currently running.

On images

If there's an official image, we only aim to support that one. I don't see a point in supporting community version of images (unless properly justified) that have official releases.

If there's no official image, we should take the one that's generally used. and provides the best support overall.

Possible alternatives

Instead of having one container per service, we could have more than one. E.g. Keycloak:

• KeycloakLegacyContainer: a container for images using the old architecture
• KeycloakContainer: a container for the new architecture

This could also apply to community images, meaning we provide support for official and community since they're equally influencial, for example.

This also could serve as a way of maintaining support for old images without having the code that support the new images cluttered. That would mean that the individual packages of the lib, instead of providing a single container, would provide more.

Bare in mind everything expressed here is my opinion and nothing else, I just cut the connectors that imply that to make the text more concise and compact.