Mature by versions instead of days

[ciltocruz]

At Scott's request, I'm starting this discussion.

Please note that the goal is NOT to eliminate maturity by days, but to expand functionality.

me said:
In fact, I'd add a rather complex possibility (I'm sure) which is to check for versions instead of days. This happens a lot with Home Assistant, for example. For instance, version 2026.7.0 is released. We know that's a major version change. I'd like to be able to update at least when two versions have passed between my current version and the one that's available when a major version is released. But this definitely deserves a separate discussion. hahaha

Scott (@scttbnsn) said:
On the version-based maturity idea (wait N releases instead of N days, like Home Assistant majors): I really like it as a supply chain control, and it's a genuinely different axis from the day-based gate, so please do open it as its own feature discussion so it doesn't get buried in this bug thread. It deserves a proper design conversation.

[scttbnsn]

Thanks for opening this properly. Let me frame the design space so the conversation has something to push against.

Why this is genuinely different from the day gate. The day gate answers "has this artifact existed long enough for the world to notice a problem with it." A version gate answers "am I far enough behind the leading edge that the versions I'd adopt have successors," which is a lagging-adoption strategy: you never run the newest release, you run N behind. Both are supply chain controls, but they fail differently, and that difference matters:

• The day gate is time-anchored. An attacker who publishes a malicious release can't make time pass faster.
• A pure version gate is not time-anchored. An attacker who can publish 2026.7.1 can also publish .2 and .3 an hour later and burn through "wait 2 versions" instantly. So a version gate probably has to compose with the day gate (both must pass), not replace it, which matches how you framed it.

The hard parts to design around:

1. What counts as "a version" per tag scheme. Semver majors/minors/patches are orderable. Home Assistant's calver mostly behaves. But latest/stable digest-only flows have no version sequence at all, and some projects tag erratically (build metadata, -ls354 suffixes, rc channels). The gate needs a defined behavior for "this container's tags aren't sequenceable": probably "fall back to days-only" rather than guess.
2. Your major-version case is really a second axis. "When a new major lands, wait until X releases exist within that major" is different from "stay N versions behind globally." The first is a stabilization gate (don't take .0 of anything), the second is a lag policy. The .0-avoidance gate ("only adopt 2026.7.x once x >= 2") seems like the higher-value, easier-to-reason-about half, and it's very Home Assistant shaped.
3. Where the version list comes from. We'd derive the sequence from the registry tag listing we already fetch, filtered by the container's include/exclude rules, so it inherits the existing per-container tag filtering semantics. That part is cheap; the policy semantics are the work.

Where this sits: it's a candidate for the roadmap, not a commitment yet. The current maturity plumbing is getting a consolidation pass first (one shared clock, honest UI), and a version gate would build on top of that once it's stable.

What would help most right now: concrete examples from your fleet. For each, the image, its tag pattern, and the rule you'd want in plain words ("transmission: only digest updates, days only", "home assistant: skip .0, wait for .2 within a major, plus 5 days"). Real cases like those decide the label/env syntax better than any abstract design. And if others reading this want it, a 👍 on the top post genuinely helps prioritize.

[ciltocruz]

From my perspective and experience... concrete examples that would define the syntax of tags/environments:

1. Example as Home Assistant (ghcr.io/home-assistant/home-assistant:latest → 2026.7.2)
   This is the use case that originated it. I want to: "skip version .0 from any monthly major release, wait until version .2 exists in that major release, plus a waiting period of 5 days." Thus, when version 2026.8.0 is released, not modify it until version 2026.8.2 is released and more than 5 days have passed. Avoiding version .0 represents the most important half, by far. Perhaps, if version .0 doesn't change in "another container-customizable maturity period," for example, 10 days, then make it a candidate for installation.

For example, with Immich, this last point is important because they release major versions somewhat unpredictably (sometimes 3 per month, sometimes it takes months to go from .0 to .1...).

2. Example with Tautulli (tautulli/tautulli:beta)
   They use SemVer. Here, we would need to store the digest of each beta release, and when there are N digests above the one we have, then apply it if the latest candidate digest has also gone through a maturity period (this would prevent the third version from being updated too quickly if four versions are released on the same day). You mentioned that supply-chain attacks allow versions to be created all the time. If the project is mature, it should be able to mitigate this in a few days. The beta version can consume versions quickly, and I want a safety margin. This digest storage needs to be prune periodically to avoid overloading DryDock. I understand that an image can be downloaded with a specific SHA hash.

3. Images with latest (Transmission, DuckDNS, etc. — :latest)
   They don't have a sequential version, so I would treat them as the In the case 2, I don't know if it's possible because "latest" is more generic.

4. Uptime Kuma/Valkey (main version fixed as :2, :9)
   I would like: "activate only within the fixed main track, wait N releases within that track + N days". Updates between main versions should require manual intervention.

Maybe, case 2 and 3, floating tags like :beta or :latest, would probably need a different approach — maybe count distinct digests published after ours, but that can come later.

The digest tracking issue can be cumbersome, I know. But I understand that systems like Docker Hub or ghrc track absolutely all images with all existing tags, meaning they're "there." hahaha

I don't know, Scott, these are just ideas I have. Really, finding and using DryDock is just my first case, but if I extrapolate it to the rest of my containers (+40), then these are the things I'm telling you.

Any input from other users would be welcome, of course.

[scttbnsn]

This is exactly what I was hoping for, a real fleet instead of a whiteboard. Recording these four as the acceptance cases for whenever this gets designed:

1. Home Assistant (calver latest → 2026.7.2): skip .0, adopt once .2 exists within the major, plus 5 days.
2. Tautulli (:beta, floating channel): stay N distinct published digests behind, plus a day-gate on the candidate so a burst of same-day releases can't rush through.
3. :latest (Transmission, DuckDNS): no sequence at all; same digest-counting idea if anything, explicitly deferrable.
4. Pinned major tracks (:2, :9 — Uptime Kuma, Valkey): N releases + N days within the pinned track; crossing majors stays manual.

Three things jump out from laying them side by side:

• Cases 1 and 4 are the same primitive wearing different clothes: "within the version family I've pinned (a calver major, a :2 track), require N successors plus N days before adopting." That's the tractable core, it works off the tag list we already fetch, and it needs no digest history.
• Cases 2 and 3 are a different primitive (distinct-digest counting on floating tags) that needs stored digest history with pruning. Worth doing eventually, but it can lag the first one without hurting it, which matches your own "can come later."
• Your unpatched-.0 timeout is the cleverest bit in here: "if .0 sits unpatched for X days, it graduates anyway." Without it, a within-family gate deadlocks on projects like Immich that sometimes never ship a quick .1. That escape valve is what makes the whole policy safe to leave unattended, and it composes naturally since it's just the existing day-gate acting as the fallback.

No timeline promises, the maturity plumbing gets its consolidation pass first and this builds on top. But the design conversation now has real acceptance cases with names on them, which is the hard part. If anyone else reading this runs a fleet with different shapes (date-tagged nightlies, -rc channels, vendor calvers), add yours, and a 👍 on the top post helps gauge demand.

[ciltocruz]

Don't take it so seriously.

Case 1. Skip the .0 version and then jump up to N versions (it could be .1, .2, or .3 if you configure a 1, 2, or 3 version offset). Not necessary .2 (because you say in your comment)

I use Home Assistant as the "latest" version. I don't have a fixed version in my Docker Compose.

But I know that DryDock, when it finds a new latest version, can determine the exact version. Therefore, I know it can recognize that the next version is .0 and skip it if the user configures it that way.

[scttbnsn]

Noted on both: the offset is configurable N, with .2 just your example. And you're right about :latest, drydock already resolves the concrete version behind it (the software-version column you see comes from the image's own version metadata), so the family gate could key off the resolved version even without a pinned tag. That actually makes the floating-tag case easier than I framed it. All captured.