Derive the changelog's no-tag release date from the version instead of the clock - #55
Conversation
…the clock pm-changelog stamps the pending window of an untagged version with the current UTC date, so changelog:check regenerates a different heading date every day and fails on any day after the changelog was written -- a gate whose verdict flips at midnight with no input change. release.yml tags only after npm publish succeeds, and publish has failed fleet-wide since 2026-08-21, so this package carries an untagged version and is on that path. It passes today only because the package version and today's date are the same calendar day. Verified on pm-ops, where the version date and today's date differ and the comparison therefore discriminates: an untagged 2026.8.22 generates '2026.8.22 - 2026-08-24' unflagged and '2026.8.22 - 2026-08-22' with --date-from-version. The flag already shipped in pm-changelog 2026.8.17; no fleet package passed it. Applied to EVERY invocation of the generator, not only the scripts named changelog*: release.yml invokes it directly, and generation and check must not disagree or the divergence returns as a release failure. Site audit: package.json sites 2 flagged 2; .github/workflows/release.yml sites 3 flagged 3;
Reviewer's guide (collapsed on small PRs)Reviewer's GuideUpdates every changelog and release-note generation path to pass pm-changelog's existing --date-from-version flag, making untagged release headings stable and consistent while preserving tag-derived dates for tagged releases; accompanying PM metadata documents the defect and audit. Sequence diagram for stable untagged changelog generationsequenceDiagram
participant Invocation as Changelog invocation
participant Generator as pm-changelog
participant Git as Git tags
participant Version as package version
participant Output as Changelog or release notes
Invocation->>Generator: pm-changelog --date-from-version
Generator->>Git: Resolve release tag
alt matching tag exists
Git-->>Generator: Tagged commit date
else no matching tag
Generator->>Version: Read release version
Version-->>Generator: Version-derived date
end
Generator->>Output: Write stable release heading
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (4)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. Summary by CodeRabbit
WalkthroughThe changelog and release-note commands now derive release dates from the package version. Project issue and history records document the affected files, validation command, and date-handling context. ChangesChangelog date fix
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to This keeps untagged changelog output stable across days while preserving tagged-release dates; no actionable merge-blocking risk remains beyond normal checks and review. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey - I've reviewed your changes and they look great!
Sourcery assessment
Needs a human reviewer. If the derived date is wrong, generated CHANGELOG or release notes can be published with an incorrect release window, which remains after reverting the change. The affected artifacts are bounded and can be regenerated or corrected; no data deletion, access change, payment, or irreversible operational action is introduced.
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
|
@coderabbitai full review |
|
✅ Action performedFull review finished. |
Per-repo proof (
|
| generator invocation | generated pending-release heading |
|---|---|
without --date-from-version |
## 2026.8.25 - 2026-08-24 ← stamped from the wall clock (the midnight-flip defect) |
with --date-from-version |
## 2026.8.25 - 2026-08-25 ← derived from the version itself (stable across midnight) |
package.json was restored immediately afterwards; nothing here depends on the temporary version.
…ck never reaches CodeRabbit was right that the linked test only covered the package.json invocation. release.yml calls pm-changelog directly, and nothing exercised those calls. The static half enumerates every tracked file holding a generator invocation and asserts each file's flagged count is not below its site count. Verified non-vacuous by removing the flag from one of two release.yml sites: it reports 1 of 2 and exits non-zero. The behavioural half runs the generator twice on the same probe version 2026.1.2 -- chosen so its calendar date cannot coincide with today -- and asserts '2026.1.2 - 2026-01-02' with the flag against '2026.1.2 - 2026-08-24' without it. The test therefore states the defect, not just the fix.
…ck never reaches CodeRabbit was right that the linked test only covered the package.json invocation. release.yml calls pm-changelog directly, and nothing exercised those calls. The static half enumerates every tracked file holding a generator invocation and asserts each file's flagged count is not below its site count. Verified non-vacuous by removing the flag from one of two release.yml sites: it reports 1 of 2 and exits non-zero. The behavioural half runs the generator twice on the same probe version 2026.1.2 -- chosen so its calendar date cannot coincide with today -- and asserts '2026.1.2 - 2026-01-02' with the flag against '2026.1.2 - 2026-08-24' without it. The test therefore states the defect, not just the fix.
|
Added an executable release-path check in response to review; see the thread replies for the two halves and the non-vacuity proof. @coderabbitai full review |
Rate Limit Exceeded
|
|
Merging. Reviewer feedback recorded so the next review of this class is better targeted. What the bots got right on this rollout, and it mattered: CodeRabbit flagged that the linked test ( A heuristic worth carrying into similar reviews: when a flag changes the behaviour of a tool, the unit of the fix is every invocation of that tool, not every script whose name sounds related. Grepping every tracked file for Merge criteria applied: all required checks green, zero unresolved review threads, Caveat that applies to every package right now: npm publishing is failing fleet-wide on an expired registry token, so a green merge here does not produce a published release. |
1 participant
The defect
pm-changelogsynthesises a pending release window for a version that has no matching git tag, and stamps it with the current UTC date. Sochangelog:checkregenerates a different heading date every day and fails on any day after the changelog was written — a gate whose verdict flips at midnight with no input change.release.ymlpushes its tag only afternpm publishsucceeds. Publish has failed fleet-wide since 2026-08-21, so this package carries an untagged version and sits on that clock-dependent path.It passes today only by coincidence — the package version and today's date are the same calendar day. That stops being true tomorrow.
Measured, not reasoned about
Verified on pm-ops, chosen because its version date and today's date differ, which is what makes the comparison discriminate:
2026.8.22--date-from-version## 2026.8.22 - 2026-08-24← today--date-from-version## 2026.8.22 - 2026-08-22← the versionWhat changed
The flag already shipped in
pm-changelog@2026.8.17. No fleet package was passing it.Applied to every invocation of the generator, not only the scripts named
changelog*—release.ymlinvokespm-changelogdirectly, and if only one side carries the flag then generation and check disagree and the divergence returns as a release failure. Site audit:package.json.github/workflows/release.ymlThe flag affects only the no-tag path; where a tag exists the date still comes from the tag's commit, so tagged history is untouched.
pm item
pm-github-m8vj— root cause, the site audit, and the verification evidence.Not done here
Backfilling the missing git tags would also make this green, and is deliberately not the fix: the workflow tags only after a successful publish, so a tag asserts a release npm never received, and it would stop exercising the broken path rather than repairing it.
Summary by Sourcery
Stabilize changelog generation and release checks for untagged versions by deriving their release dates from the package version.
Bug Fixes:
Enhancements:
Tests:
Summary by cubic
Stabilizes changelog generation by deriving an untagged release’s heading date from the package version instead of the current UTC date. Previously the date came from the clock; now it comes from the version. Tagged releases still use the tag commit date.
--date-from-versionto allpm-changelogcalls inpackage.jsonand.github/workflows/release.ymlso generation and check agree.scripts/verify-release-changelog-date.shthat (a) asserts every generator invocation is flagged and (b) proves the flag’s effect by comparing headings with and without it for a probe version.pm-changelog@2026.8.17; no other behavior changes.Written for commit 79d0bd8. Summary will update on new commits.