Closed qhaas closed 7 months ago
This is a good suggestion, however curl :latest gets you that by default, until we bump, for example 8.7 to 8.8 ... though this transition may also include security fixes. I am not a big fan of :latest or such tag indirection but I can see its value.
Any client is free today to make this choice by inspecting version label and/or querying registry eg. the 'ask' here is to put the 'smarts' at the registry instead of the client ... I am inclined to keep status quo and closing this issue out.
thank you for taking the time to file this suggestion.
Currently, each curl container image release tag is either
latest
or major.minor.patch specific.For those wanting the latest bug / security fixes without any possible command-line interface (CLI) / API backwards compatibility breaking changes, it would be useful to also provide a tag that only includes the major.minor version that 'points' to the latest patch release of said major.minor branch. This has proved useful for other containers.
For example, under such a scheme, if one were to
docker pull docker.io/curlimages/curl:8.2
at time of writing, one would get the underlyingdocker.io/curlimages/curl:8.2.1
image. Should one re-rundocker pull docker.io/curlimages/curl:8.2
after a hypothetical 8.2.2 is released, thendocker pull docker.io/curlimages/curl:8.2
would retrieve it. Likewise, any docker compose files could be 'locked' into the 8.2 release and still get the latest patch release 8.2.2.