chadtmiller.com/knotless

Switch repository

Loading…

What changes

knotless 0.7.0 is knope release --override-version 0.7.0 run over the 8 change files on main. It bumps the workspace version from 0.6.0 to 0.7.0 in Cargo.toml and Cargo.lock, writes the version's CHANGELOG.md section, and removes the change files.

Once this lands and main's checks pass at it, release.yml builds the client for every target and publishes it as release 0.7.0 of the knotless package, then tags the commit v0.7.0.

Why

main is to name review.knotless.dev as a gate (knotless protect --gate). A client that does not know gates refuses to merge or queue into a branch whose rule names one, so the gate goes on only once a release that knows it is out. It also brings what has landed since 0.6.0:

• assignees and asking for reviews;
• organization admins changing settings from the command line;
• gates, from the command line, MCP and the settings page;
• checks --images keeping the newest run's pictures;
• unscoped exclusive labels, the login page, and a merge whose head branch cannot be deleted.

knope alone would make this 0.6.1, as it bumps a 0.x minor change as a patch. It is 0.7.0 because of the new features.

How it was checked

knope release --override-version 0.7.0: all six workspace crates' lock entries move to 0.7.0. The build is left to CI.

Changeset: none

Shortcomings

A published version can't be taken back.

🤖 Generated with Claude Code

This is a mechanical release 0.7.0, and it checks out. The workspace version in Cargo.toml and the six knotless crates in Cargo.lock all move from 0.6.0 to 0.7.0. The other 0.6.0 in Cargo.lock, at line 1170, is a third-party crate. The 8 change files in .changeset/ are all removed, none are left over, and each appears word for word in the new CHANGELOG.md section. The features are listed under Features and the fixes under Fixes. deploy.yml still sets KNOTLESS_CLIENT_MINIMUM to 0.6.0. That is right, because nothing here raises the minimum client. I didn't run a build and didn't check CI. The description leaves the build to CI, so confirm it passes before this merges, since release publishing starts from main once its checks pass.