v1.5.2-rc.3

Full Changelog: v1.5.2-rc.2...v1.5.2-rc.3

[1.5.2-rc.3] — 2026-07-11

Added

• Informational version visibility for pinned tags (#498). A specific-precision, unlabeled, non-loose pinned tag (e.g. nginx:1.25.3) still gets digest-only comparison for update actions — that pin-gate behavior from rc.2 is unchanged — but the container result now carries a new updateInsight: { tag, kind } field showing the best newer same-family tag that exists in the registry, purely as information. It reuses the exact same strict-style family matching used for actionable updates (prefix + suffix/variant compatibility + matching numeric-segment count + CalVer leading-zero rules) — no exception is carved out for major-version jumps; strict matching never restricted those to begin with. One narrow widening is scoped to this informational channel only: a prerelease-pinned tag (e.g. 1.5.2-rc.1) can see its own bare GA release (1.5.2) here, but that never makes the bare GA release an actionable update candidate — the actionable path rejects it just as before, even under dd.tag.family=loose or a permissive dd.tag.include filter. What's new is exposing this comparison at all for pinned tags, since the pin gate itself already blocks acting on any of it. Ties at the same numeric version prefer the tag whose suffix template exactly matches the pinned tag's. This is additive only: updateAvailable, updateKind, and trigger dispatch are all unaffected, so nothing new fires because of it. On by default; opt out per watcher with DD_WATCHER_{name}_TAG_PIN_INFO=false. Surfaced in the UI as an informational "Newer available" badge next to the existing update-state badges.

Fixed

• dd.tag.family=loose no longer bypasses the suffix/variant guard in isSemverFamilyMatch(). A pinned nginx:1.2.3-ls132 container could previously be offered a bare 1.2.4 (wrong variant) as an update candidate under loose policy — loose mode was only ever meant to relax prefix equality and CalVer leading-zero rules, not let updates cross a suffix/variant boundary entirely. The guard now applies unconditionally regardless of policy.
• The candidate sort in sortSemverDescending() now prefers the exact-suffix-template match over a merely-compatible one when two candidates tie at the same numeric version (e.g. preferring 1.2.5-alpine over 1.2.5-alpine3.21 for a 1.2.3-alpine reference). Semver treats the suffix as a prerelease field, so without this fix the wrong variant could outrank the exact match purely on prerelease-string ordering.