Feature request: fetch and display all intermediate release notes between current and target version

[steilerDev]

Summary

Release-notes enrichment currently fetches notes for exactly two versions — the current tag and the update-target tag — and shows them side by side. When a container is several versions behind, there is no way to see what changed in the intermediate releases. That gap matters: deciding whether to update often hinges on a breaking change, migration step, or security fix introduced in a version between current and latest, which is invisible today.

Please consider fetching and displaying all releases between the current and target version, so operators can make an informed update decision.

Current behavior (v1.5.0)

enrichContainerWithReleaseNotes fetches only two single-tag releases:

• app/watchers/providers/docker/release-notes-enrichment.ts:27 — currentReleaseNotes for the current tag
• app/watchers/providers/docker/release-notes-enrichment.ts:43 — releaseNotes for the update-target tag (container.result.tag)

Each is a single-release lookup:

• app/release-notes/providers/GithubProvider.ts:193 — GET /repos/{owner}/{repo}/releases/tags/{tag}

The UI renders the two side by side (ui/src/components/containers/ReleaseNotesLink.vue, container fields releaseNotes / currentReleaseNotes). Nothing aggregates the releases in between, and if current and target resolve to the same release the second fetch is skipped (release-notes-enrichment.ts:38-41).

Requested behavior

When an update is available and current/target tags are both semver-resolvable:

1. Enumerate the repo's releases between current (exclusive) and target (inclusive) — e.g. via the paginated GET /repos/{owner}/{repo}/releases list endpoint — and order them by semver.
2. Surface them as an ordered list (newest→oldest or oldest→newest) in the release-notes popover, in addition to (or merged with) the current/target panels that exist today.
3. Keep it best-effort: fall back gracefully to today's two-panel behavior when intermediate releases can't be determined.

Technical considerations / nuances to call out

• Ordering requires semver. Intermediate selection only works when tags are semver-comparable (and after any transformTags is applied). Non-semver / date / rolling tags can't be ordered into a range — fall back to the current two-version view for those.
• Tag ↔ release matching. The existing buildTagVariants logic (prefix v, .git handling, etc.) must be reused so listed releases map back to the watched tags correctly. Some repos also publish tags without a corresponding GitHub release — those would have no notes and should be skipped or shown as "no release notes."
• API cost & rate limits. A range fetch is more expensive than two point lookups. The /releases list endpoint is paginated (up to 100/page), so a large gap could need several calls. Sensible bounds would help — e.g. a configurable cap (DD_RELEASE_NOTES_MAX_INTERMEDIATE, default ~20) with a clear "N older releases not shown" indicator rather than silent truncation.
• Auth interaction. This amplifies the existing token/trust limitation: for untrusted sources the token is suppressed, so range fetching would hit the 60 req/h unauthenticated GitHub limit fast. Related: Allow DD_RELEASE_NOTES_GITHUB_TOKEN to override source-repo "trust" for release-notes lookups (and document narrow scoping) #452 (allow DD_RELEASE_NOTES_GITHUB_TOKEN to override trust). Authenticated range fetches would be far more viable.
• Caching. Per-release notes are already cached by (provider, repo, tag, trusted); the range result should be cached too (e.g. keyed by repo + currentTag + targetTag) to avoid re-listing every watch cycle.
• Payload size in agent mode. In agent mode the enriched notes ride along in the agent → controller snapshot. A full range of release bodies could be large; consider truncating bodies, sending summaries/links, or lazy-loading the full set via the existing /api/containers/{id}/release-notes endpoint on demand.

Why this matters

For anything more than a patch bump, the relevant "should I update?" information (breaking changes, required migrations, deprecations, security fixes) frequently lives in the releases between what I'm running and the latest — which Drydock fetches the endpoints of but not the middle. Showing the full intermediate changelog turns the release-notes popover into an actual upgrade-decision aid.

Environment

• Version: 1.5.0

[scttbnsn]

Shipped in v1.5.1-rc.3 (#459, squash 1819478): intermediate release notes between the running and target version, lazy-loaded in the popover via the new GET /api/containers/{id}/intermediate-release-notes endpoint. Capped by DD_RELEASE_NOTES_MAX_INTERMEDIATE.

[scttbnsn]

@steilerDev to call this out directly: the intermediate range landed in v1.5.1-rc.3. When a container is several versions behind, the release-notes popover now fetches everything between the running tag (exclusive) and the update target (inclusive) and shows it in one place. It's best-effort and semver-only, so date and rolling tags (latest, stable) fall back to the two-panel current/target view. Cap the range with DD_RELEASE_NOTES_MAX_INTERMEDIATE (default 20, set to 0 to disable); over the cap you get a non-silent "N older releases not shown" notice. It's lazy-loaded when the popover opens, so it adds no ongoing payload weight.

rc.3 is a prerelease (ghcr.io/codeswhat/drydock:1.5.1-rc.3). Give it a try and let me know how it looks before GA.