Suggestion: Add versions of container images #270

Activity

1. mag37 commented on Mar 9, 2026

   

   mag37

   on Mar 9, 2026

   Owner

   More actions

   I'd love to easily implement this, though it has been discussed a few times before, see #159 and #165 for some of it.

   I've got a few comments in my notes to try to explore this further, but what I've tested is to try to grab info with

   --format '{{ index .Config.Labels "org.opencontainers.image.version" }}'
   --format '{{ index .Config.Labels "org.opencontainers.image.ref.name" }}'
   --format '{{ index .Config.Labels "org.label-schema.version" }}'
   

   But it's very inconsistent.

   If anyone finds a good way to do this that seems consistent no matter the source of the container (different creators etc), I'd love to hear!

   This is not something I'll currently pursue but I happily receive suggestions if someone else want to dig deeper.

   👍React with 👍2Reacted by ColinShark and Rob
2. mag37

   added

   help wantedExtra attention is neededExtra attention is needed

   enhancementNew feature or requestNew feature or request

   on Mar 9, 2026
3. ColinShark commented on Mar 10, 2026

   

   ColinShark

   on Mar 10, 2026

   Author

   More actions

   That's very fair. Thanks for the swift reply anyway!

   👍React with 👍1Reacted by Robin Ivehult
4. mag37

   marked FEATURE REQUEST: check updates for containers with fixed version, not only :latest #284 as a duplicate of this issue on May 13, 2026
5. simonlpaige commented on May 17, 2026

   

   simonlpaige

   on May 17, 2026

   More actions

   The core challenge here is that Docker images don't have a standardized, machine-readable version label. org.opencontainers.image.version is an OCI annotation, but its adoption is inconsistent across images. Even if present, it often reflects the image build version rather than the application version users expect (e.g., 1.2.3-alpine vs 1.2.3).

   A more reliable approach would be to parse the image tag itself. For images following semver in their tags (e.g., image:2.0.6), you could extract the current and new tag. However, many tags use non-versioned schemes (latest, stable, alpine), or include build metadata, making this heuristic fragile.

   A practical middle ground: add an optional --show-tags flag that compares the repository tag currently used by the container against the tag available in the registry, and displays that diff instead of attempting to parse semantic versions. This avoids false positives from label parsing and doesn't require changes to image metadata. The output would be image:tag -> image:newest_tag, which at least shows users something changed in the reference, even if it's not a semver bump.

   For version-aware filtering, that would need to be a separate feature gated behind a strict semver check, because any non-standard tag format would break the comparison logic.

   👍React with 👍1Reacted by Robin Ivehult
6. mag37 commented on May 20, 2026

   

   mag37

   on May 20, 2026

   Owner

   More actions

   Thank you @simonlpaige for your input!
   Indeed - the versions and labeling is very inconsistent and the naming convention and custom tags etc is all over the place.

   I like the --show-tags idea (though we currently dont have long options) though I'm not sure there's a clean and consistent way of grabbing the newest / most recent tag.
   You can get a list of all available tags with regctl tag ls repo/container but how would you determine what's the most recent and accurate tag for the specific container?

   Just to show an example of the inconsistency, I ran this:

   for i in $(docker ps --filter "name=$SearchName" --format '{{.Names}}') ; do \
   echo "------------ $i ------------" ; \
   ContImage=$(docker inspect "$i" --format='{{.Config.Image}}') ; \
   ./regctl tag ls "$ContImage" | sort -n | tail -n5 ; done

   Which gave me this:

   ------------ metube ------------
   2026.04.16
   2026.04.18
   2026.04.21
   2026.04.26
   2026.04.28
   ------------ tinyfilemanager ------------
   latest
   master
   2.4.7
   2.5.3
   ------------ web2_mariadb ------------
   110.4.20mariabionic-ls27
   110.4.20mariabionic-ls28
   110.4.20mariabionic-ls29
   110.4.21mariabionic-ls30
   110.4.21mariabionic-ls31
   ------------ web2_nginx ------------
   92eacdda-ls106
   924d280e-ls108
   924d280e-ls109
   8349a582-ls112
   333315c5-ls114
   ------------ flatnotes ------------
   v5.5.1
   v5.5.2
   v5.5.3
   v5.5.4
   28-synology-port-issue
   ------------ whoogle ------------
   1.2.0.0-test
   1.2.1-test
   1.2.2
   1.2.3
   1.2.4
   ------------ uptime-kuma ------------
   2.3.1-slim-rootless
   2.3.2
   2.3.2-rootless
   2.3.2-slim
   2.3.2-slim-rootless
   ------------ pg ------------
   18.4-alpine
   18.4-alpine3.22
   18.4-alpine3.23
   18.4-bookworm
   18.4-trixie
   ------------ homer ------------
   22.02.1-arm64v8
   22.02.2
   22.02.2-amd64
   22.02.2-arm32v7
   22.02.2-arm64v8
   ------------ pingvin-share ------------
   v1.8
   v1.8.2
   v1.9
   v1.9.0
   v1.9.1
   ------------ snippet-box ------------
   arm
   dev
   latest
   ------------ dockge ------------
   1.4.0
   1.4.0-beta.0
   1.4.1
   1.4.2
   1.5.0
   

   Many of them are clean and nice, so while it's not impossible it's not failsafe and consistent.
7. ckaotik commented on May 21, 2026

   

   ckaotik

   on May 21, 2026

   Last edited by ckaotik

   More actions

   I think there are two different scenarios to follow: Floating tags (e.g. "latest", "3", feature tags, ...) and pinned tags (e.g. "3.2.1" or "v1.2.3-beta1"). And then there are floating tags that also have a pinned tag equivalent (same digest), to make it even more confusing. I wouldn't even try to parse semantic versions, that's a lose-lose situation.

   Pinned tags should be comparable using tag names alone - however, figuring out which tag names are relevant, is another story. E.g. a postgres container on 17-bookworm could update to bookworm/18-bookworm (which is the same digest), one on 18.2-alpine3.22 could be interested in 18.3-alpine3.22, 18.4-alpine3.22 etc. We should be able to decide based on the (floating) tag that was used by our container, or if there is none simply display the latest tag (the last entry in your lists).

   For floating tags, we'd need the tag + timestamp/date to allow comparisons. When they have a pinned tag equivalent, that should also be displayed. I guess my personal preference would be something like <floating> @<pinned> (YYYY-MM-DD), or a slightly shorter variant:

   grimmory: latest @3.0.0 (2026-04-22) -> latest @3.1.0 (2026-05-14)
   grimmory (latest): 3.0.0 (2026-04-22) -> 3.1.0 (2026-05-14)
8. mag37 commented on Jun 5, 2026

   

   mag37

   on Jun 5, 2026

   Owner

   More actions

   Thank you @ckaotik - yeah parsing semantic versions isn't really feasible.

   I think the issue here is 1. figuring out what is relevant in the current context. 2. deciding what's considered "latest" within that context.

   You can filter a little bit of the regctl tag ls output like this

   ./regctl tag ls python --include "^3.*" | sort -V
   

   But how do we base that filtering on the current image and make it generic enough to work across all types of naming?
   Especially when the local tag is :latest where locally is not tied to any versioning at all (in many cases, if they dont set labels).