Abandonment heuristic produces false positives for mature tools with server-side data (e.g., govulncheck)

[AndriyKalashnykov]

Summary

Renovate's abandonment heuristic (abandonmentThreshold) relies solely on release-date age. For packages whose CLI is intentionally stable while their functional data updates server-side, this produces a confident false positive — the package is marked abandoned in the Dependency Dashboard even when the project is actively maintained.

A representative example is golang.org/x/vuln/cmd/govulncheck:

Signal	Value	Interpretation
Last GitHub release	v1.1.4 on 2025-01-13	~15 months old at time of writing
Last push to master	2 days ago (2026-04-15)	Actively maintained
Open issues	0	Actively maintained
Archived	No	Actively maintained
Ownership	golang/ (official Go sub-repo)	Non-trivial backing
Functional updates	Continuous at vuln.go.dev	Server-side — CLI doesn't need frequent releases

The tool is explicitly designed with a stable CLI because the thing that actually moves — the CVE database — lives on a remote endpoint. A release-age-only heuristic can't distinguish "abandoned" from "mature, stable, server-updated".

Why this matters

Users see govulncheck (and tools like it) reported as abandoned on their Dependency Dashboard, then have to either:

1. Hunt for a replacement (there isn't an equivalent Go vulnerability scanner with call-graph analysis).
2. Silence the flag locally via packageRules + abandonmentThreshold: "5 years", which every downstream repo has to re-discover independently.

This noise erodes trust in the Dependency Dashboard's abandonment signal.

Proposal

Extend the abandonment heuristic to consider at least one additional signal beyond release age. Candidates in rough order of preference:

1. Commit activity on the default branch — if the most recent push is within the abandonment threshold, the package is not abandoned regardless of release age. This is the clearest fix and directly addresses stable-CLI projects.
2. Archived flag — mark as abandoned when archived: true, regardless of release age. (Already a strong signal for the opposite conclusion.)
3. Open-issue velocity / count — zero or near-zero open issues combined with no recent push is a stronger abandonment signal than release age alone.

Implementation sketch: for any datasource that Renovate already looks up through the GitHub API (which returns pushed_at and archived), fold those fields into the abandonment decision. A package is abandoned iff both age(last_release) > threshold and age(last_push) > threshold — never by release age alone.

Motivating cases beyond govulncheck

Other mature CLIs that could trip the same false positive:

• benchstat (golang.org/x/perf/cmd/benchstat) — Go team's benchmark diff tool, similar "stable CLI / active data" pattern.
• shellcheck when its release cadence slows (project is very active historically but releases are uneven).
• actionlint (similar pattern — long periods between releases).

Current workaround

Per-package abandonmentThreshold override in renovate.json:

{
  "packageRules": [
    {
      "matchDepNames": ["golang.org/x/vuln/cmd/govulncheck"],
      "abandonmentThreshold": "5 years"
    }
  ]
}

Works, but every downstream repo must re-discover and apply it. A heuristic fix would help the whole ecosystem.

Environment

• Renovate version: 43.128.0
• Manager: custom.regex (via # renovate: inline comment in .mise.toml)
• Datasource: go
• depName: golang.org/x/vuln/cmd/govulncheck

Previously filed as Issue

Originally filed as #42725 and auto-closed per the Issues-are-for-maintainers policy (needs-discussion label). Re-filing here as requested.

---

Happy to open a PR if the maintainers agree with the general approach; let me know if you'd prefer a specific implementation direction (e.g., fold pushed_at into isAbandoned at the datasource level vs. in a separate post-lookup step).