Support major.minor tag in docker images

[Alirexaa]

Description

In .NET Aspire We try to use major.minor image versions if possible, so we automatically get patch updates without needing to change our code. Right now Elasticsearch image doesn't support this image format.

Is possible to support this image tag format?

dotnet/aspire#4430

[elasticsearchmachine]

Pinging @elastic/es-delivery (Team:Delivery)

[mark-vieira]

Currently we don't do any "dynamic" tagging of our images. @elastic/release-eng I'm sure this topic has come up before, but probably in the context of latest but there is precedent for tags like 8 or 8.15 which would point to the latest for that major or major.minor.

[jmlrt]

Historically, our policy has always been to consider released artifacts as immutable. This means that when you download a file from our website or pull an image with a specific tag from our registry, you should always receive the exact same artifact. This approach is crucial for several reasons:

• Consistency in Support: Support teams should not have to handle different behaviors from artifacts that are supposed to be identical but come from different commits or builds.
• Controlled Upgrades: Upgrade operations, even for patch releases, should always occur in a controlled manner, initiated by users. This ensures that nodes of our products do not get automatically upgraded unexpectedly by restarting with different versions from a newer image they pulled.
• Version Uniformity in Clusters: It is essential that all nodes in a cluster use the exact same version. This prevents situations where a new node might be added and picks up a new version while the existing nodes are still running the older version.

We are always open to discussions and potential changes if they make sense after considering the perspectives of all impacted teams.

[mark-vieira]

Since there are no plans to use such a tagging scheme I'm going to close this issue.

[eerhardt]

or pull an image with a specific tag from our registry, you should always receive the exact same artifact.

I agree that customers should be able to specify an immutable version of the artifact. And that is possible by fully qualifying the image tag name <major>.<minor>.<patch> if you follow semantic versioning. You'd never ship the same patch version more than once. If you needed to make an update, you'd increment the patch number.

But there are a set of customers who want to automatically get security patches without having to change their source code every time a security patch comes out.

elasticsearch is doing just that with its dependency on redhat/ubi/ubi9 here:

elasticsearch/distribution/docker/src/docker/iron_bank/hardening_manifest.yaml

Lines 14 to 17 in 1be0f2b

	# Build args passed to Dockerfile ARGs
	args:
	BASE_IMAGE: "redhat/ubi/ubi9"
	BASE_TAG: "9.3"

Here you are saying "give me the latest 9.3 version" and new versions of 9.3 have been released since #102721 was merged to update to 9.3.

I don't know the best practices around docker tag management, I'm sure everyone has their own opinions. But looking at other well-known docker containers, having tags that float across patches seems to be the norm.

• https://hub.docker.com/_/redis/tags
• https://hub.docker.com/_/postgres/tags
• https://hub.docker.com/_/mysql/tags
• https://hub.docker.com/_/busybox/tags