curl / curl-container

curl images
MIT License
66 stars 12 forks source link

Major.minor tagged releases #35

Closed qhaas closed 7 months ago

qhaas commented 1 year ago

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 underlying docker.io/curlimages/curl:8.2.1 image. Should one re-run docker pull docker.io/curlimages/curl:8.2 after a hypothetical 8.2.2 is released, then docker 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.

xquery commented 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.