Repository navigation
Publish as bootintel, not bootintel-cli - #7
Merged
Merged
Conversation
cargo install bootintel-cli installed a command called bootintel. That mismatch is a papercut every single user hits, and the binary name has never been in question, so the package name is what was wrong. crates.io cannot rename a crate, so this publishes under the new name and yanks bootintel-cli 0.4.1. That version had 0 downloads, so nothing breaks, and the old name stays reserved under the same account so nobody else can claim it. bootintel was unclaimed, which also means the brand name stops sitting open on the registry. Numbered 0.4.2 rather than republishing 0.4.1 under the new name. main was exactly tag cli-v0.4.1, so reusing that version would have put a crate on crates.io whose contents differed from the tag and the shipped archives, and a crates.io version can be yanked but never reused. Same reasoning that made the first publish 0.4.1 instead of 0.4.0. Scope kept deliberately narrow. The published package name changed, along with the cargo commands that name it: the release workflow's publish step, the releasing doc, and the README install line. The package directory stays crates/cli and the prose references to the project as "bootintel-cli" in CONTRIBUTING, SECURITY and the Nix flake are left alone, because renaming those churns paths and text for no user-visible gain. bootintel-detectors keeps its suffix: it is a library and the suffix is descriptive there, not redundant the way -cli is beside a binary called bootintel. Verified: cargo metadata reports bootintel 0.4.2, 274 tests pass, cargo deny reports advisories, bans, licenses and sources all ok, rustfmt clean. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
cargo install bootintel-cliinstalled a command calledbootintel. The binary name was never in question, so the package name is what was wrong.bootintel-clibootintelbootintelbootintelcrates.io cannot rename a crate, so this publishes under the new name and
bootintel-cli0.4.1 gets yanked. It had 0 downloads, so nothing breaks, and the old name stays reserved under the same account.bootintelwas unclaimed, so this also stops the brand name sitting open on the registry.Why 0.4.2 and not a republished 0.4.1.
mainwas exactly tagcli-v0.4.1. Reusing that version would have put a crate on crates.io whose contents differed from the tag and the shipped archives, and a crates.io version can be yanked but never reused. Same reasoning that made the first publish 0.4.1 rather than 0.4.0.Scope kept narrow. The published package name and the cargo commands that name it: the release workflow's publish step, the releasing doc, the README install line. The package directory stays
crates/cli, and prose references to the project as "bootintel-cli" in CONTRIBUTING, SECURITY and the Nix flake are untouched, because renaming those churns paths and text for no user-visible gain.bootintel-detectorskeeps its suffix. It is a library, where the suffix is descriptive rather than redundant.Verified locally:
cargo metadatareportsbootintel 0.4.2, 274 tests pass,cargo deny checkreports advisories, bans, licenses and sources all ok, rustfmt clean.