Why was an update rolled back?

[wsw70]

I switched to "Auto" by default and to automatic upgrades. As expected, after a forced check, all of my stale containers were updated. All but one:

Its image in the relevant docker compose file is getmeili/meilisearch:v1.13.3. This is therefore (very likely) a container that will never get updated.

In the history, I see only one entry for that container:

What does this mean?

• the update should not be suggested at all (in my opinion) as it is outside the bounds of the semver version in the compose file
• it seems that it was not updated after all (good!) but somehow "rolled back"

[Will-Luck]

You're right on both points. The update to v1.14 shouldn't have been suggested for a container pinned to v1.13.3, and the rollback happened because the meilisearch v1.14 container failed its health check after the update.

This has been fixed in v2.4.0. Sentinel now uses the tag's version precision to determine the update scope:

• 3-part tags like v1.13.3 - only patch updates within the same minor version (1.13.x)
• 2-part tags like 1.25 - updates within the same major version (1.x)

So getmeili/meilisearch:v1.13.3 will now only be offered 1.13.x patches (of which there are currently none newer than v1.13.3), and won't be offered v1.14 or v1.15 anymore.

The rollback behavior itself worked correctly as a safety net - Sentinel detected the health check failure and reverted to the previous image.

[wsw70]

This has been fixed in v2.4.0. Sentinel now uses the tag's version precision to determine the update scope:

• 3-part tags like v1.13.3 - only patch updates within the same minor version (1.13.x)
• 2-part tags like 1.25 - updates within the same major version (1.x)

I believe this is incorrect. When I have x.y I want to stay at x.y, possibly with patch updates (x.y.z) but the upper bound should be x.y

In other words, to take your example and assuming semver, this would be

• 3-part tags like 1.13.3 - no updates
• 2-part tags like 1.13 - "patch" updates within the same minor version (1.13.x)
• 1-part tags like 1 - "minor" and "patch" updates within the same major version (1.x.y)

[Will-Luck]

You make a fair point about 2-part tags. After thinking about it more (and getting some feedback from others too), I'm leaning toward tightening the behavior so that both 2-part and 3-part tags stay within the same major.minor. So nginx:1.25 would only surface 1.25.x patches, same as nginx:1.25.0 would.

The reasoning is pretty simple - if someone pins to 1.25, they probably picked that minor version for a reason. Jumping them to 1.26 feels like the kind of thing that should be a conscious decision, not something that just shows up in a scan result.

For 3-part tags though, I'd still want to show patch updates rather than nothing. The way I see it, if you truly want "don't touch this container" you'd set the policy to pinned. The version scope is more about "what range of updates are relevant" vs the policy being "what should Sentinel actually do about it."

Does that separation make sense to you? Curious if you see cases where even patch-level notifications for a 3-part tag would be unwanted.

[Will-Luck]

Actually, I've been thinking about this more and rather than picking one behavior and hardcoding it, what if we just make it configurable?

Something like an "Update Scope" setting on the settings page with two options:

• Patch only - stay within the same major.minor (so 1.25 only gets 1.25.x)
• Minor + Patch - stay within the same major (so 1.25 gets 1.26, 1.27, etc.)

3-part tags like 1.25.0 would always be patch-only regardless, since the precision already makes that clear. The setting would only affect how 2-part tags are interpreted.

That way you can pick whichever model fits your setup. For people running things like meilisearch where minor bumps can break things, patch-only makes sense. For images where minors are safe incremental updates, the broader scope might be preferable.

Default would be patch-only, but you could open it up if you wanted. Thoughts?

[wsw70]

This is a good idea. I would, however, add a 3rd option to honor the patch level . Some stacks pin the versions so it would be good not to have them update. I know that you can use the relevant "do not touch" label, but people can forget :)

Generally speaking, my impression (this is not a written rule) is that when someone sets a tag on the image, it is to say "this and everything below". This is the reason serious images have releases with major, minor, and patch for the same image.

This is why the two options you suggested would not allow for a "I care only about the major version, anything else is fine" (in addition to the other end of the spectrum, the one that does not modify the patch level).

Typically I have (as examples)

• Traefik in the major version only, I am fine with the rest because changes are not likely to break everything, and even if they do it will be easy to fix (as opposed to a completely different stucture like it was the case of Caddy for instance).
• Home Assistant has a weird semver-like system and by setting 2026.2 I expect anything below to come in
• A specific docker compose that wants version 12.3.6 and I will not risk contradicting it :)
• and plenty of :latest or not tagged images

[wsw70]

The reasoning is pretty simple - if someone pins to 1.25, they probably picked that minor version for a reason. Jumping them to 1.26 feels like the kind of thing that should be a conscious decision, not something that just shows up in a scan result.

I re-read your comment and I think we fully agree -- I just extend this to all levels:

• choosing a major version means that I can have anything within it (minor + patches)
• choosing a minor version means that I can have anything within it (patches)
• choosing a patch version means that I can have anything within it ah, there is nothing below so it stays at that fixed version

Or in general, "everything below that is fine"

[Will-Luck]

The version scope was tightened in v2.4.0 (2-part tags now stay within the same minor). The configurable version scope feature has been tracked as #48, covering the full "strict" model we discussed here: 1-part = minor+patch, 2-part = patch only, 3-part = no updates.

Closing this discussion. Thanks for the thorough feedback on how version precision should be interpreted, it shaped the design.