#10762·pipeline

Do we care if dependabot bumps release branches' minimum Go version?

Author: vdemeesterCreated Sep 16, 2026Updated Sep 17, 2026
Labelskind/misc

What happened

sigstore/sigstore v1.10.10 (released after v1.10.9) bumped its own go.mod from go 1.25.0 to go 1.27.0 (sigstore/sigstore#2415). Because Go's module graph rules take the max go directive across all dependencies, updating to v1.10.10 forces the consuming go.mod's go line up to 1.27.0 too — as a side effect of what dependabot presents as an unremarkable "patch" bump (kind/misc, semver-patch).

This has now happened on two release branches:

  • release-v1.15.x: already merged via [release-v1.15.x] bump github.com/sigstore/sigstore/pkg/signature/kms/gcp (1.10.9 → 1.10.10), which silently bumped go.mod from go 1.26.4 to go 1.27.0. CI stayed green because the branch's code happened to already be gofmt-clean for that Go version.
  • release-v1.12.x: same sigstore bump is currently open in several PRs (#10747-#10751). There the jump is go 1.25.10 → go 1.27.0, which changed gofmt's output for two pre-existing files and turned lint red (pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go, pkg/reconciler/pipelinerun/pipelinerun_test.go).

In both cases, a dependency-patch-level dependabot PR raised the minimum Go version for an LTS maintenance branch, without any maintainer explicitly deciding that should happen. It was only surfaced by chance because release-v1.12.x's code wasn't gofmt-clean under Go 1.27 and CI turned red; release-v1.15.x merged the same class of change without anyone noticing.

The question

Do we care whether dependency updates bump the minimum Go version on maintenance/LTS release branches?

  • If yes: we probably want a guardrail — e.g. flag/hold dependency updates that change the effective go directive on release branches for explicit review, similar to how k8s.io/* and go.opentelemetry.io/* are already excluded from semver-major/minor auto-updates in .github/dependabot.config.yml.
  • If no: nothing to do beyond fixing the immediate release-v1.12.x lint failure alongside its sigstore bump, and this issue can be closed.

No urgency/incident — just flagging the pattern so it's a deliberate choice rather than something that quietly slips in via whichever dependabot PR happens to merge first.

/kind misc