nagonag: detect real major updates (v1→v2, v2→v3, …) via path-incremented probes #2

New issue

Open

opened 2026-05-17 01:09:20 +02:00 by heiko · 1 comment

heiko commented

2026-05-17 01:09:20 +02:00

Owner

Current behaviour

The major-update detection in the "Detect module updates" step compares the leading numeric segment of .Version and .Update.Version (both stripped of v), and creates a [nagonag] major update: … issue when they differ.

Because go list -m -u <modpath> only reports upgrades within the same import path, and v2+ Go modules carry their major version in the path (github.com/foo/bar/v2), .Update.Version will never cross a real major boundary for modules at v1+. The current comparison therefore only catches v0 → v1 transitions (where the import path doesn't change). True v1→v2, v2→v3, etc. upgrades are silently missed.

What we'd like

For each direct dependency M at current major vN, also probe whether M/v(N+1), M/v(N+2), … exist on the configured GOPROXY. If a higher-major module path resolves, flag it as a major update needing manual attention, just like the current code does for v0→v1.

Sketch of the approach

For each direct, non-replaced module from go list -m -u -json all (the same set the detect step already iterates):
- Extract the current major N from the module path (.../vN suffix, or implicit v0/v1 if no suffix).
- Probe GET $GOPROXY/<path>/v(N+1)/@latest (and possibly +2, +3 with a small upper bound, e.g. 5 steps).
- On any 200 response, record (path, v(N+1)) as a major-update candidate.
Surface candidates the same way the existing code does:
- Title: [nagonag] major update: <path> <current> -> v(N+1).x.y (<branch>)
- Body: link to the new module path, explain manual review is required.

Considerations / tradeoffs

One extra HTTP probe per direct dep per scan — needs to be batched/parallelised or rate-limited; otherwise a large dep tree slows the scan.
Module proxy can be private (GOPRIVATE / GOPROXY=off for some modules) — probes have to honour those settings or be skipped silently for affected paths.
Some maintainers publish v2+ from a branch without a path bump (technically incorrect, but common in v0.x → v1.x territory). Those would 404 on the probe and stay invisible — same as today.
Deduplication: don't open a new issue if one already exists for the same (path, target-major) pair.

Out of scope (for now)

Automatic PRs for major upgrades. Major bumps almost always require code changes (import path rewrite, API migration), so they should remain issue-only.

## Current behaviour The major-update detection in the "Detect module updates" step compares the leading numeric segment of `.Version` and `.Update.Version` (both stripped of `v`), and creates a `[nagonag] major update: …` issue when they differ. Because `go list -m -u <modpath>` only reports upgrades *within the same import path*, and v2+ Go modules carry their major version in the path (`github.com/foo/bar/v2`), `.Update.Version` will never cross a real major boundary for modules at v1+. The current comparison therefore only catches **v0 → v1** transitions (where the import path doesn't change). True v1→v2, v2→v3, etc. upgrades are silently missed. ## What we'd like For each direct dependency `M` at current major `vN`, also probe whether `M/v(N+1)`, `M/v(N+2)`, … exist on the configured `GOPROXY`. If a higher-major module path resolves, flag it as a major update needing manual attention, just like the current code does for v0→v1. ## Sketch of the approach - For each direct, non-replaced module from `go list -m -u -json all` (the same set the detect step already iterates): - Extract the current major `N` from the module path (`.../vN` suffix, or implicit `v0`/`v1` if no suffix). - Probe `GET $GOPROXY/<path>/v(N+1)/@latest` (and possibly +2, +3 with a small upper bound, e.g. 5 steps). - On any 200 response, record `(path, v(N+1))` as a major-update candidate. - Surface candidates the same way the existing code does: - Title: `[nagonag] major update: <path> <current> -> v(N+1).x.y (<branch>)` - Body: link to the new module path, explain manual review is required. ## Considerations / tradeoffs - One extra HTTP probe per direct dep per scan — needs to be batched/parallelised or rate-limited; otherwise a large dep tree slows the scan. - Module proxy can be private (`GOPRIVATE` / `GOPROXY=off` for some modules) — probes have to honour those settings or be skipped silently for affected paths. - Some maintainers publish `v2`+ from a branch without a path bump (technically incorrect, but common in v0.x → v1.x territory). Those would 404 on the probe and stay invisible — same as today. - Deduplication: don't open a new issue if one already exists for the same (path, target-major) pair. ## Out of scope (for now) - Automatic PRs for major upgrades. Major bumps almost always require code changes (import path rewrite, API migration), so they should remain issue-only.

heiko added the

nagonag

label

2026-05-17 01:09:20 +02:00

heiko commented

2026-05-22 11:38:07 +02:00

Author

Owner

AI attribution comment added per repository instruction for this open issue.\n\n(co)authored by ai:gpt-5-codex