0.3.1 — branch-prefix recognizes GitHub merge subjects
Patch release with one fix surfaced by dogfooding. Anyone using --strategy branch-prefix (the default) inside GitHub Actions was silently no-op'ing on every merge with status=no_merge_commit, even on real merge commits. 0.3.1 fixes the default to recognize GitHub's PR-merge subject format alongside GitLab's git merge format. No changes to the GitHub or GitLab providers themselves.
If you're not on branch-prefix, or your CI is GitLab, you can skip this release — no behavior change for you.
The bug
BranchPrefixStrategy.decide gated the bump computation on a single substring check:
if self.config.merge_mark_text not in subject: # default: "Merge branch"
return Bump.NONE"Merge branch" is GitLab's default git merge feature/foo subject (Merge branch 'feature/foo' into main). GitHub's PR merges produce a different subject — Merge pull request #N from OWNER/BRANCH — which does not contain "Merge branch". So every branch-prefix consumer running inside GitHub Actions hit the gate, fell through to Bump.NONE, and reported no_merge_commit even when the commit was clearly a merge.
The docs in docs/strategies/branch-prefix.md explicitly called this out as a limitation under defaults — the fix turns "explicitly limited" into "works".
Surfaced concretely by dogfooding 0.3.0 on this repo's own CI (PR #5, PR #6 — both merged via GitHub PR, both no-op'd with no_merge_commit).
The fix
BranchPrefixConfig.merge_mark_text: str = "Merge branch" becomes a plural tuple with both formats in the default:
merge_mark_texts: tuple[str, ...] = pydantic.Field(
default=("Merge branch", "Merge pull request"),
min_length=1,
)BranchPrefixStrategy.decide now checks any(mark in subject for mark in self.config.merge_mark_texts). Out-of-the-box correct for both providers.
Breaking change
The field rename merge_mark_text → merge_mark_texts (singular → plural tuple) affects anyone who was overriding the default via env or config. Specifically:
SEMVERTAG_BRANCH_PREFIX__MERGE_MARK_TEXT="X"(old) →SEMVERTAG_BRANCH_PREFIX__MERGE_MARK_TEXTS='["X"]'(new — note the plural field name + JSON-tuple env shape).BranchPrefixConfig(merge_mark_text="X")(old) →BranchPrefixConfig(merge_mark_texts=("X",))(new).
Acceptable pre-1.0: this knob shipped in 0.1.0 with the documented use case "non-default merge conventions" and has no known consumers overriding it. Users who were overriding it get a clear pydantic ValidationError at startup — easy to fix.
Migration
For the common case (using defaults): no action needed. 0.3.1 just works.
For anyone overriding the old field: rename per above. The new shape accepts a tuple of substrings, so existing single-string overrides become a 1-tuple — and you can now list multiple marks (e.g. squash-merge prefixes alongside the standard ones) without writing custom code.