Skip to content

v2.2.0 — what "up to date" actually means

Latest

Choose a tag to compare

@amayer1983 amayer1983 released this 07 Aug 12:40

If you pin your images to a version tag — nginx:1.25.3 rather than nginx:latest — this release is for you, and it also fixes something that has been quietly misbehaving for you.

A pinned tag now tells you a newer version exists

A version tag is immutable. Its digest never changes, so Docksentry reported "up to date" forever — including long after 1.26 shipped. That statement was true and misleading in the same breath.

@LeeNX raised exactly this in #33 and asked for it to be explained. The issue got closed answering a different question, and his actual request was never acted on. He was right.

The Status page now shows it:

nginx   1.25.3   ↑ 1.26.2

Advisory only. Docksentry will not switch to it, will not offer a button for it, and does not count it among your pending updates. Pinning a version is a statement of intent — moving you off it unasked could destroy a database. To move, change the tag in your compose file, which is what you would have done anyway, now knowing there is something to move to.

It costs nothing against your Docker Hub pull limit: measured, /tags/list returns no rate-limit headers at all and leaves the manifest budget untouched at 100/hour.

And a defect that was already affecting you

The function that finds the highest matching tag was matching the wrong ones. Its filter read if prefix and not ts.startswith(prefix) — so a tag beginning with a digit, which is most tags, produced an empty prefix and skipped the check entirely. Everything the SemVer pattern would accept then qualified, and that pattern allows a leading something-.

Measured against the real registry:

linuxserver/qbittorrent:4.6.5  ->  arm64v8-20.04.1

An Ubuntu version number, on the wrong architecture.

This is not new code, and it is not only used by the new badge. _is_major_bump calls it — so if you run linuxserver images with major-confirmation enabled, you were being asked to confirm every ordinary patch update as a major version jump. That is fixed.

The same shape existed at the other end of the tag: nextcloud:29.0.4-apache was being compared against the plain 32.0.13, a different image variant. Suffixes have to match too.

What is left, and stated rather than hidden

Some repositories carry two numbering schemes in the same shape — linuxserver/qbittorrent tags both its own 4.6.5 and its Ubuntu base 20.04.1, and nothing in the tag text separates them. Candidates more than three majors ahead are read as a different scheme. That is a heuristic, it can be wrong in both directions, and it therefore only ever suppresses a badge or a confirmation prompt — it never causes an update to be applied. A real major jump (radarr 5 → 6) still registers.

Two-component tags like postgres:16.3 and redis:7.2-alpine are not covered at all: SemVer needs three numbers. They still receive security rebuilds like any other pinned tag.

docs/updates.md now explains all of this in one table — the documentation @LeeNX asked for four months ago.

Upgrading is the usual docker pull ghcr.io/amayer1983/docksentry:latest, or nothing at all with auto-selfupdate on.