release: dependency bumps can never reach consumers, because dependabot says chore and semantic-release ignores chore

[Lutherwaves]

Filed to hold the discussion from #246, which is closed in favour of this issue so the decision can be made before any config changes.

The problem

Two tool defaults compose into an outcome nobody chose:

• .github/dependabot.yml sets no commit-message.prefix, so dependabot uses its default of chore(deps):.
• release.yml runs go-semantic-release, which with no .semrelrc uses the conventional-commits default: feat: → minor, fix: → patch, chore: → nothing.

Result: a dependency bump can never reach a consumer through a tag.

This was visible on main as of 2026-09-10: between v0.19.0 (2026-08-06) and the mql fixes, there were 6 commits, all chore, and the latest release stayed v0.19.0 for over a month. The Release workflow ran green on every one of them and correctly cut nothing.

Why it matters for a consumed library

For an application the default is right. magic is consumed, so a bump changes what downstream builds against.

Go's minimal version selection softens this — a consumer can go get golang.org/x/net@vX itself rather than wait on us — so this is a visibility problem more than a capability one. But the visibility part is real:

• govulncheck and Dependabot alerts downstream key off the module version. "v0.19.0 plus five weeks of dependency fixes" and plain "v0.19.0" are indistinguishable to any tooling looking at a consumer's go.mod.
• A consumer who does want the bumps has to pin a pseudo-version (v0.19.1-0.2026...), which is a worse thing to carry in a go.mod than a real tag.

This is also the convention Renovate adopts by default: production dependency updates are fix(deps):, dev dependencies are chore(deps):, precisely so the former cut an adoptable patch.

Proposed change

One block, gomod only:

commit-message:
  prefix: "fix"
  include: "scope"

include: "scope" preserves the existing (deps) scope, so titles stay fix(deps): bump ... and keep passing the Conventional Commits check. github-actions and devcontainers keep chore — neither affects what downstream builds against.

Trade-offs to weigh before doing it

• Release noise. This turns roughly-weekly dependency PRs into roughly-weekly patch tags. That is the real cost and the main reason to say no.
• commit-message.prefix is per-ecosystem, not per-group. Go has no dev-dependency notion, so it is all-or-nothing for gomod — there is no way to release the patches group but not minor.
• Majors would cut only a patch. A major group bump would still release as a patch, understating it. That already needs a human to add a BREAKING CHANGE footer where one genuinely applies; this change neither fixes nor worsens that.

Alternative

Keep chore and cut a release by hand when a bump matters. That works — it just has to be remembered, and the month-long gap above suggests it is easy not to.