From 8d0ebcc306142e0c4d1e5969ec59eb25014e033e Mon Sep 17 00:00:00 2001 From: sksizer Date: Wed, 23 Sep 2026 01:53:16 -0500 Subject: [PATCH] fix(changelog): match the crate-prefixed tags release-plz creates MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit `tag_pattern = "v[0-9].*"` matched none of this workspace's release tags. release-plz prefixes them with the crate name — `ontogen-v0.7.0`, `ontogen-core-v0.5.0` — so the pattern only ever matched the four legacy tags from before the workspace split, `v0.1.0` through `v0.3.0`. git-cliff could then find no current release to bound the range against and emitted an almost-empty changelog. The 0.7.1 release PR lists one commit; fourteen are in range. Same config, same repo, two boundaries: git-cliff … ontogen-v0.7.0..main 4 Added, 1 Changed, 9 Fixed git-cliff … --unreleased 1 Changed Unset, every tag counts and the newest bounds the range correctly; release-plz passes the per-package range explicitly regardless. Also skip `^merge`. A `merge: …` subject parses as a conventional commit, so the stack-merge commits were forming their own `### merge` section in the release notes. --- cliff.toml | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/cliff.toml b/cliff.toml index e3289bd2..be6e6ae0 100644 --- a/cliff.toml +++ b/cliff.toml @@ -48,6 +48,10 @@ conventional_commits = true filter_unconventional = true split_commits = false commit_parsers = [ + # A `merge: …` subject is a conventional commit as far as the parser is + # concerned, so without this the stack-merge commits form their own + # "### merge" section in the release notes. + { message = "^merge", skip = true }, { message = "^feat", group = "Added" }, { message = "^fix", group = "Fixed" }, { message = "^refactor", group = "Changed" }, @@ -65,5 +69,12 @@ commit_parsers = [ ] protect_breaking_commits = false filter_commits = false -tag_pattern = "v[0-9].*" +# No `tag_pattern`. release-plz creates crate-prefixed tags in a workspace +# (`ontogen-v0.7.0`, `ontogen-core-v0.5.0`), and the previous pattern +# `v[0-9].*` matched none of them -- only the four legacy tags from before the +# workspace split (`v0.1.0` .. `v0.3.0`). git-cliff could then find no current +# release to bound the range and emitted an almost-empty changelog, which is +# how the 0.7.1 release PR came to list one commit out of fourteen. Unset, +# every tag counts, so the newest one bounds the range correctly; release-plz +# passes the per-package range explicitly regardless. sort_commits = "oldest"