heavy-duty/cast
7
0
Fork 0
Code Issues 4 Pull requests Projects Releases 3 Packages Wiki Activity Actions 1

3 releases 3 tags

RSS feed
  • 0.1.1 2f30105b6e

    0.1.1 Stable

    github-actions[bot] released this 2026-07-19 23:03:50 +00:00 | 58 commits to main since this release

    Fixed

    • The release ceremony re-arms the changelog, and CI notices when it
      doesn't       (#113) — stamping ## Unreleased into ## X.Y.Z — DATE is
      done by hand in the ceremony PR; no workflow writes this file, and
      nothing put the heading back. So main sat with the shipped section on
      top and no ## Unreleased above it — this repo's state from 0.1.0
      until this entry. A PR authored before a release and merged after has
      its entry land under whatever heading now occupies that position: the
      release that already shipped. Git does that cleanly. The stamped
      heading and the incoming entry never overlap textually, so the one
      signal an author trusts — "git told me to look" — is missing exactly
      when the result is wrong. rig watched it happen (heavy-duty/rig#66, the
      origin of this fix): an entry landed inside published ## 0.1.0 an
      hour after 0.1.0 shipped, and was caught only because someone was
      reading. The published release body is never at risk — release.yml
      extracts notes from the tree at the tag, before anything late can merge
      — which is also why nobody notices: the file that drifts is the one
      only maintainers read. Three moves. ## Unreleased is back above
      ## 0.1.0 (this entry re-creating it is the repair). CONTRIBUTING's
      ceremony step now re-arms in the same diff that stamps. And
      test/release.test.ts keys the rule to package.json: a stamped top
      section is legal while the version is bare — the ceremony's own tree,
      and main until the -dev bump — but once the version says -dev, the
      top section must be ## Unreleased. That is the distinction #108 had
      to collapse to make the ceremony shippable at all, recovered rather
      than reverted: the ceremony stays green at every step, and a disarmed
      dev main goes red. The re-arm also forced the older extraction guard
      to move. It asserted that the top section extracts non-empty, which
      the re-armed ceremony tree — a deliberately empty ## Unreleased above
      the stamp — makes false by construction: the re-arm and the guard would
      have contradicted each other, and the next release PR would have been
      unshippable for a second time, the way #108 was. Keying to the top
      section was only ever a stand-in for "the section release.yml will
      publish", so the assert now names that section directly — on a bare
      version the ## X.Y.Z being shipped, on a -dev tree the newest
      stamped one. Existence is checked with it: a bare version with no
      matching section is a bump that never stamped, which used to pass every
      test and fail only after the merge, in release.yml's notes step,
      past the ship decision and leaving main with a minted, unreleased
      version to repair by hand. A double re-arm — two ## Unreleased
      headings, the extracted section silently the empty one — is red too.
      box and rig carry the same fix (heavy-duty/box#110,
      heavy-duty/rig#67); rig#67 retargeted the identical assert for the
      identical reason.
    Downloads