release.py: tag message taken from newest commit, can misdescribe the release #188

New issue

Closed

opened 2026-06-06 23:23:29 +00:00 by coilysiren · 1 comment

coilysiren commented

2026-06-06 23:23:29 +00:00

Owner

release.py derives the annotated-tag summary from the wrong commit, so the tag message can describe a change that is not in the tagged tree.

Where: scripts/release.py, in main():

summary = entries[0][0] if entries else f"release {new_tag}"
tag_msg = f"Release {new_tag}: {summary}"

entries comes from commits_since(prev) = git log {prev}..HEAD, newest first. So entries[0] is the most recent commit subject since the last tag, picked regardless of whether it is representative of the release.

Observed: the v0.14.0 tag message reads Release v0.14.0: feat(code-comments): extend comment discipline to YAML, but that commit (177f895) is NOT in the v0.14.0 tree - it landed afterward. Confirmed:

git show v0.14.0:agentic_os/check_code_comments.py | grep YAML_EXTS   # -> no match
git merge-base --is-ancestor 177f895 v0.14.0                          # -> false

So the tag message advertises a feature the tag does not contain. Misleading for anyone reading git tag -n or release notes to decide what a pinned rev ships.

Likely contributing factor: history was rewritten (rebase) after a prior release computed the message, leaving the tag annotation describing a commit that moved. But the core issue stands: the summary should reflect the release, not a single arbitrary newest subject.

Fix options:

Summarize the release from the conventional-commit set actually being tagged (e.g. counts per type, or the highest-impact feat/fix), not entries[0].
Or list the subjects in the tag body rather than crowning one in the subject line.
Either way, generate the message from commits that are ancestors of the commit being tagged (HEAD at tag time), so a later rebase cannot strand it.

Low priority / cosmetic - no functional impact on consumers. Surfaced while cutting v0.15.0 for #187.

`release.py` derives the annotated-tag summary from the wrong commit, so the tag message can describe a change that is not in the tagged tree. **Where:** `scripts/release.py`, in `main()`: ```python summary = entries[0][0] if entries else f"release {new_tag}" tag_msg = f"Release {new_tag}: {summary}" ``` `entries` comes from `commits_since(prev)` = `git log {prev}..HEAD`, newest first. So `entries[0]` is the **most recent** commit subject since the last tag, picked regardless of whether it is representative of the release. **Observed:** the v0.14.0 tag message reads `Release v0.14.0: feat(code-comments): extend comment discipline to YAML`, but that commit (177f895) is NOT in the v0.14.0 tree - it landed afterward. Confirmed: ``` git show v0.14.0:agentic_os/check_code_comments.py | grep YAML_EXTS # -> no match git merge-base --is-ancestor 177f895 v0.14.0 # -> false ``` So the tag message advertises a feature the tag does not contain. Misleading for anyone reading `git tag -n` or release notes to decide what a pinned rev ships. **Likely contributing factor:** history was rewritten (rebase) after a prior release computed the message, leaving the tag annotation describing a commit that moved. But the core issue stands: the summary should reflect the release, not a single arbitrary newest subject. **Fix options:** - Summarize the release from the conventional-commit set actually being tagged (e.g. counts per type, or the highest-impact feat/fix), not `entries[0]`. - Or list the subjects in the tag body rather than crowning one in the subject line. - Either way, generate the message from commits that are ancestors of the commit being tagged (HEAD at tag time), so a later rebase cannot strand it. Low priority / cosmetic - no functional impact on consumers. Surfaced while cutting v0.15.0 for #187.

coilysiren added the

label

2026-06-17 07:04:56 +00:00

coilysiren commented

2026-06-17 08:23:04 +00:00

Author

Owner

Backlog burndown 2026-06-17: closing low-priority (P3/P4) to bring the open count to a manageable level. Nothing lost — reopen if this resurfaces. Batch tag: burndown-2026-06.

Backlog burndown 2026-06-17: closing low-priority (P3/P4) to bring the open count to a manageable level. Nothing lost — reopen if this resurfaces. Batch tag: `burndown-2026-06`.

coilysiren

2026-06-17 08:23:04 +00:00