v2.6.0 — leftover backups, pinned databases, and every connection in one place

Two things you should read even if you skip the rest: <name>_old containers were piling up forever, and the "newer version" badge now works for pinned databases — which it never has.

Leftover backups

Every update renames the running container to <name>_old before creating its replacement and drops that backup once the new one is healthy. A run whose process died in between left one behind — and then it stayed, because nothing here has ever removed a leftover backup container. cleanup_images prunes images; _prune_old_backups, despite the name, deletes backup directories on disk; and the recovery path stepped over them deliberately, on the stated grounds that the backup "belongs to the cleanup grace period". No such thing exists.

@LeeNX found three of them and reasonably concluded his containers were not updating (#56). They were updating fine. He was looking at the debris.

Recovery removes the backup once the live container proves the swap finished — and only then, and only the name from its own journal: a *_old container you named that way yourself is yours. The successful-update path forces the removal like every other call site already did. And any leftovers you already have are named on the Status page with the command to remove them — not a button, because deleting a container this process did not create is your call.

Pinned tags: two numbers, and staying in your own major

postgres:16.3 used to get no badge at all. SemVer wants three numbers, so two-component tags were a documented gap — and that gap swallowed exactly the images people pin most. Measured on Docker Hub: postgres publishes 32 two-component tags and not one three-component tag. The feature could never fire for it.

It now compares against tags of the same shape — 7.2 belongs with 7.4, not 7.4.1, and redis carries 9 of one and 53 of the other, so mixing them would be the ordinary case rather than a corner.

And the badge now stops at the major you pinned to: 16.3 hears about 16.4, never 17.0. A Postgres major is not a tag change, it is pg_upgrade, and a container that swapped only the tag would not open its old data directory. This changes what three-component tags advise too, deliberately — at the top of your own line you now see nothing, which is the honest answer: within what you pinned, you are current. Major-version confirmation is untouched and still looks across majors.

Every connection in one place, and each says what it is doing

The notification channels moved to a Connections page in 2.3.0–2.5.0; this release finishes it.

Each card now says one of three things — Active, Switched off, or Not active — missing: recipients — with a switch and a test button. Telegram has the same switch as the rest now; off means off, notifications and commands both. Every card also says what that way can do: sends only, sends and takes commands, takes commands, because "Discord" appears on two cards and nothing said they were different things.

Turning off the last one asks first. Docksentry would keep checking and updating with nowhere to say so.

Also

• A container labelled io.containers.autoupdate is badged: Podman's own updater has it on a systemd timer, so two things have an opinion and whichever fires first wins. Reported, never acted on.
• The auto-update report leads with the outcome — 3 updated · 1 failed — because a long report splits across several Telegram messages and the answer was spread over all of them.
• An unreachable host lists the endpoints Docker itself knows about. DOCKER_HOSTS is typed by hand and a typo looks exactly like a machine that is down.
• The boot line said Telegram: ON for a Telegram that was switched off, and the startup check would let you boot an instance with no way to report anything and no interface to fix it. Both refuse now.

---

Nothing to do on upgrade. Every channel you had stays on; every CHANNEL_*_ENABLED variable defaults to true.