Skip to content

v1.1.2

Choose a tag to compare

View all tags
@github-actions github-actions released this 17 Aug 12:57
Immutable release. Only release title and notes can be modified.
v1.1.2
ad6fee3
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Canonical source: ad6fee3; Canonical dist/commitlore.mjs SHA-256: 96141692eaeff0d8a711fe5e54c2d26dadf9c96045847db2d8e65ed245cee62f

Upgrading no longer reports a version it did not install.

If you upgraded to 1.1.0 or 1.1.1, check this first

install.sh printed current -> v1.1.1 and left <data-root>/current pointing at the previous release. commitlore init records the hook's interpreter as <data-root>/current/dist/commitlore.mjs precisely so hooks follow upgrades — so every repository on that machine kept validating commits with the old build while the CLI reported the new one.

readlink ~/.local/share/commitlore/current

If that names an older version than commitlore --version reports, you are affected. Re-running the installer at 1.1.2 repairs it, and commitlore doctor reports the same split in its own words:

warn  commit-msg hook — commitlore.bin is version 1.0.2, but this CLI is 1.1.1 —
      the hook validates every commit with 1.0.2, so anything fixed since then does not apply here

Nothing was lost and no record was corrupted. What was wrong is which build was checking them.

The cause

BSD mv follows a destination that is a symlink to a directory and moves the source into it, returning zero. The && held, the success line printed, and the temporary link sat inside the old release directory where the rename had actually gone:

~/.local/share/commitlore/current                                 -> v1.0.2   (untouched)
~/.local/share/commitlore/v1.0.2/current.commitlore-install.53786 -> v1.1.1   (where mv put it)

A first install creates the link and cannot reach this, which is why it shipped in 1.0.2 and survived two releases. Reproducing it needs two installs, and the tests now do that.

The fix

The rename says it means rename — -h on BSD, -T on GNU, falling back to unlink-and-rename, which is not atomic but fails visibly rather than silently keeping the old build.

And the success line is printed only after reading the link back. That is the half that matters: every mechanism available here can return zero without moving anything, and that line is the only thing an operator reads before trusting an upgrade.

Also in this release

Windows CI exercises the host-detection branches that only a comment was holding. A GitHub runner has no coding agents, so those branches never ran there. A planted claude.cmd and codex.cmd make them run, and a leftover .claude.json with no executable is now required to stay notDetected — the rule 1.1.1 documented and nothing enforced.

The README lines saying host wiring needs 1.1.1 or later do not move with this release. They name the version that fixed it.

Full notes: CHANGELOG.md. Upgrading from 1.1.x is a drop-in; nothing about capture, policy or records changed.

Assets 3
Loading