From b84d433492a66db68175d5dc7e7ed816d48e44a5 Mon Sep 17 00:00:00 2001 From: BootIntel Agent Date: Sat, 26 Sep 2026 10:58:24 +0000 Subject: [PATCH] Publish as bootintel, not bootintel-cli 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) --- .github/workflows/cli-release.yml | 4 ++-- CHANGELOG.md | 19 ++++++++++++++++++- Cargo.lock | 6 +++--- Cargo.toml | 2 +- README.md | 7 +++++-- crates/cli/Cargo.toml | 9 +++++++-- docs/releasing.md | 18 ++++++++++++------ 7 files changed, 48 insertions(+), 17 deletions(-) diff --git a/.github/workflows/cli-release.yml b/.github/workflows/cli-release.yml index 0db2aa8..aeda3ec 100644 --- a/.github/workflows/cli-release.yml +++ b/.github/workflows/cli-release.yml @@ -364,7 +364,7 @@ jobs: echo "::error::bootintel-detectors ${{ inputs.version }} never appeared on the index." exit 1 - - name: Publish bootintel-cli + - name: Publish bootintel env: CARGO_REGISTRY_TOKEN: ${{ secrets.CARGO_REGISTRY_TOKEN }} - run: cargo publish -p bootintel-cli + run: cargo publish -p bootintel diff --git a/CHANGELOG.md b/CHANGELOG.md index bfb2d0f..f1a2e84 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -8,6 +8,22 @@ All notable changes to bootintel-cli are documented here. Format follows [Keep a ## [Unreleased] +## [0.4.2] — 2026-09-26 — published as `bootintel` + +### Changed +- **The crate is now published as `bootintel`, not `bootintel-cli`.** + `cargo install bootintel` installs a command called `bootintel`, which + is what the binary has always been named. The `-cli` suffix made every + user type one name and get another. crates.io cannot rename a crate, so + this is a new crate; `bootintel-cli` 0.4.1 is yanked. It had 0 downloads, + so nothing breaks, and the old name stays reserved under the same account. + The package directory stays `crates/cli`, since renaming it would churn + paths for no user-visible gain. +- 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 release + archives. A crates.io version can be yanked but never reused. + ## [0.4.1] — 2026-09-26 — publishable to crates.io No user-visible behaviour change, so PATCH per the policy above. @@ -329,7 +345,8 @@ Initial release. All six subcommands live; five branch-based milestones (M1-M5) - PDF report download subcommand — server-side endpoint exists but no client-side wrapper yet. - Windows support — the Rust code compiles for Windows and the release workflow builds it, but install.sh doesn't handle Windows yet (`.ps1` installer is a follow-up). -[Unreleased]: https://github.com/bootintel/cli/compare/cli-v0.4.1...HEAD +[Unreleased]: https://github.com/bootintel/cli/compare/cli-v0.4.2...HEAD +[0.4.2]: https://github.com/bootintel/cli/releases/tag/cli-v0.4.2 [0.4.1]: https://github.com/bootintel/cli/releases/tag/cli-v0.4.1 [0.4.0]: https://github.com/bootintel/cli/releases/tag/cli-v0.4.0 [0.3.1]: https://github.com/bootintel/cli/releases/tag/cli-v0.3.1 diff --git a/Cargo.lock b/Cargo.lock index bf0cb82..d6e5ec5 100644 --- a/Cargo.lock +++ b/Cargo.lock @@ -130,8 +130,8 @@ source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "b588b76d00fde79687d7646a9b5bdf3cc0f655e0bbd080335a95d7e96f3587da" [[package]] -name = "bootintel-cli" -version = "0.4.1" +name = "bootintel" +version = "0.4.2" dependencies = [ "anyhow", "arboard", @@ -154,7 +154,7 @@ dependencies = [ [[package]] name = "bootintel-detectors" -version = "0.4.1" +version = "0.4.2" dependencies = [ "regex", ] diff --git a/Cargo.toml b/Cargo.toml index 4d35cd2..07763ee 100644 --- a/Cargo.toml +++ b/Cargo.toml @@ -19,7 +19,7 @@ members = ["crates/detectors", "crates/cli"] resolver = "2" [workspace.package] -version = "0.4.1" +version = "0.4.2" edition = "2021" rust-version = "1.90" license = "Apache-2.0" diff --git a/README.md b/README.md index 512498e..faaca2a 100644 --- a/README.md +++ b/README.md @@ -92,7 +92,10 @@ docker run --rm -i ghcr.io/bootintel/cli:latest scan - < boot.log # Nix flake (in-repo): nix run github:bootintel/cli -- version -# Cargo (from source): +# Cargo (from crates.io): +cargo install bootintel + +# Cargo (from a source checkout): cargo install --path crates/cli --features tui ``` @@ -112,7 +115,7 @@ Pin to a release tag (`@cli-v0.4.0`) or a commit SHA — **never `@main`** (a co **Homebrew:** the formula template lives at `packaging/homebrew/bootintel.rb`. A public `bootintel/homebrew-tap` for `brew install bootintel` is planned. -**crates.io:** `cargo install bootintel-cli` is not available yet. The crates are publishable and the release workflow has the job wired, pending a registry token. See [docs/releasing.md](docs/releasing.md). +**crates.io:** `cargo install bootintel` installs the latest published release. It builds from source, so it needs a Rust toolchain and takes a few minutes; the one-liner above drops a prebuilt binary in seconds. See [docs/releasing.md](docs/releasing.md) for how releases are cut. **Windows:** the one-liner above downloads + SHA256-verifies the latest release, extracts `bootintel.exe` into `$env:USERPROFILE\.local\bin`, and prints a `setx PATH` line if that dir isn't already on your PATH. Override with `$env:BOOTINTEL_VERSION` / `$env:BOOTINTEL_INSTALL_DIR`, or use `$env:BOOTINTEL_TARBALL` for offline installs. Currently x86_64 only — ARM64 users need `cargo install --path crates/cli --features tui`. diff --git a/crates/cli/Cargo.toml b/crates/cli/Cargo.toml index fa33bbd..96d3318 100644 --- a/crates/cli/Cargo.toml +++ b/crates/cli/Cargo.toml @@ -1,5 +1,10 @@ [package] -name = "bootintel-cli" +# Published as "bootintel", matching the binary it installs. It was +# "bootintel-cli" for exactly one release (0.4.1, 0 downloads, since +# yanked): cargo install bootintel-cli producing a command called +# bootintel is a papercut every user hits. The directory stays +# crates/cli because renaming it would churn paths for no gain. +name = "bootintel" description = "Interactive UART capture + streaming boot-log analysis. Free scan + share; server-side CVE matching + exploit paths via bootintel.com API." version.workspace = true edition.workspace = true @@ -19,7 +24,7 @@ path = "src/main.rs" # version when packaging for crates.io, which rejects a bare path dep. # This is what publish = false was working around; publishing # bootintel-detectors first makes the workaround unnecessary. -bootintel-detectors = { path = "../detectors", version = "0.4.1" } +bootintel-detectors = { path = "../detectors", version = "0.4.2" } clap = { version = "4.5", features = ["derive", "wrap_help", "env"] } # Shell-completion emitters for `bootintel completions `. Version # tracks the clap major/minor (4.5). No default features — we only use diff --git a/docs/releasing.md b/docs/releasing.md index af4ab7d..4054b3d 100644 --- a/docs/releasing.md +++ b/docs/releasing.md @@ -65,9 +65,9 @@ having no brew line at all. ## Publishing to crates.io -Order is not optional. `bootintel-cli` declares `bootintel-detectors` with +Order is not optional. `bootintel` declares `bootintel-detectors` with both a path and a version, so the library must be on the index before the -binary crate can be packaged. `cargo package -p bootintel-cli` fails with +binary crate can be packaged. `cargo package -p bootintel` fails with `no matching package named bootintel-detectors` otherwise. The `publish-crates` job does this in order, waits for the index to become @@ -77,9 +77,15 @@ consistent, and then publishes the binary crate. Dispatch the workflow with ```sh cargo publish -p bootintel-detectors # wait for the index -cargo publish -p bootintel-cli +cargo publish -p bootintel ``` -After the first successful publish, update the Install section of `README.md` -to offer `cargo install bootintel-cli` instead of the from-source line. Do not -add it before then. +The README's Install section offers `cargo install bootintel` as of 0.4.2, +the first release published under that name. Keep the caveat that it builds +from source: the install one-liner is faster for anyone who just wants the +binary. + +The crate was `bootintel-cli` for exactly one release, 0.4.1, which has been +yanked. crates.io cannot rename a crate, so the move was to publish under +the new name and yank the old. The old name stays reserved under this +account either way, so nobody else can claim it.