[zmofei]

Bumps the version to 1.0.0, states the 1.0 compatibility rules, and moves the Unreleased entries under a ## 1.0.0 - 2026-10-21 heading. 1.0.0 covers what is on main plus #104, which lands first so the first release that sends telemetry events never sends them with a user's token. #67 and #103 land after it, with their entries under Unreleased.

• Cargo.toml and Cargo.lock: 1.0.0.
• CHANGELOG and CONTRIBUTING: versions now follow plain semver (a breaking change bumps the major version, a new feature the minor, a fix the patch), replacing the pre-1.0 rule. A command marked beta stays outside the compatibility promise until its label is removed. AGENTS.md says the same.
• README: the version-pinned install examples now name 1.0.0.
• New tests/changelog.rs fails while the version in Cargo.toml has no ## <version> - <date> CHANGELOG heading. Nothing in the release pipeline checks this, so a tag could otherwise ship with every entry still under Unreleased.
• CHANGELOG: dropped an unsupported claim from the Arm64 Windows entry, and added an entry for Move rustls-webpki and webpki-roots past two advisories #106's rustls-webpki/webpki-roots advisory fix.

Tagging and publishing happen in the release pipeline, not here. If this merges on a later day, the heading's date needs updating.

Testing: fmt, clippy and the full suite pass locally on macOS, and mapbox --version prints 1.0.0. The new test failed before the heading was added and passes with it. Rebased on main after #106. I also merged #104 and then this branch onto main locally: no conflicts, clippy clean, 919 tests pass, and #104's changelog entries land inside 1.0.0 as intended. The README pins point at a v1.0.0 that won't exist until the release is published.

No downstream or operational impact until the release is cut.

[mattpodwysocki]

Thanks @zmofei. The bump itself looks right to me: Cargo.toml and Cargo.lock agree, the semver wording is consistent across CHANGELOG, CONTRIBUTING and AGENTS.md, and the beta carve-out matches how workflow behaves. I simulated merging #67, #103 and #104 and then this onto main, and it's all clean, no conflicts, cargo build --locked is happy and mapbox --version prints 1.0.0.

The body says this stays a draft until the other three merge, but it's currently marked ready, so nothing stops it going in early. Could you flip it back to draft? Worth knowing too: nothing in the release checks looks for a ## 1.0.0 - <date> heading, so a v1.0.0 tag would go through with every entry still under Unreleased if that last commit got missed.

A couple of things for that last commit:

• The native Arm64 Windows entry still says the Apple Silicon VM case is "the larger of the two populations this serves". Nothing backs that up, so I'd drop the clause. Since this is the first release with that build, it might be worth calling out near the top of the 1.0.0 section.
• After #103 lands, its entry is missing a blank line before the mapbox usage bullet.
• Optional: the sample output in docs/commands.md still shows mapbox 0.3.0.

[zmofei]

Thanks @mattpodwysocki. Changed plans: 1.0.0 now covers only what's on main, and #67, #103 and #104 land after it. So this is ready rather than draft, and c7b09f1 adds the ## 1.0.0 - 2026-10-21 heading.

• Dropped the Arm64 clause in 1a6b08c. I didn't move the entry to the top.
• Fixed the blank line on Add mapbox commands search and commands list #103's branch (6e3e44c).
• 54cae9b adds tests/changelog.rs, which fails while the version has no dated CHANGELOG heading.
• The base is Move rustls-webpki and webpki-roots past two advisories #106 for now so advisories passes. It goes back to main once Move rustls-webpki and webpki-roots past two advisories #106 merges.
• docs/commands.md's 0.3.0 samples are captured output, so I'll recapture them from the 1.0.0 release build.

[mattpodwysocki]

Thanks @zmofei for adding the changelog test, that closes the gap nicely. With the new order there are a couple of things I'd like to sort out before we tag:

1. Since #104 now lands after 1.0.0, this would be the first release that sends telemetry events at all (0.3.0 only had the User-Agent), and it sends them with the user's own token when they have one, a tk. login or an sk. in the env. The docs describe that accurately, but it's the exact exposure #104 removes, and tokens stored with events can't be pulled back later. Could we land #104 before tagging? It's approved and green.
2. I tried merging #103 and #104 on top of this branch. Both merge cleanly, but their changelog entries end up inside the 1.0.0 section, and #104 rewrites two existing 1.0.0 entries in place, so the 1.0.0 notes would say telemetry never used your token. The new test doesn't catch it since the heading is still there. If #104 goes first that part goes away; otherwise both need a rebase that puts their entries under Unreleased.
3. CONTRIBUTING.md still uses mapbox workflow as the beta example, but it won't be in 1.0.0 and nothing on main marks a command beta yet. Could we keep the general rule and drop the example until #67 lands?
4. Small ones: a line for #106's rustls-webpki/webpki-roots advisory fix would match how 0.2.0 noted its rustls fix, and the heading date will need to match the day it's actually tagged.

[zmofei]

@mattpodwysocki Agreed on all four, thanks. #104 now lands before the tag, so its entries go into 1.0.0 as written and the in-place rewrite stops being a problem. #103 still lands after, with its entry under Unreleased. In 5efcc36: dropped the mapbox workflow example from CONTRIBUTING and added a line for #106's advisory fix. 4e5d166 dates the heading 2026-10-22 for the tag.

[mattpodwysocki]

Thanks @zmofei, looks good. The advisory entry matches RUSTSEC-2026-0381/0382, and the CONTRIBUTING change reads well. I simulated your order (#104, #103, #108, then this) on main: everything merges cleanly, Unreleased ends up empty, 1.0.0 picks up commands search and the CLI-token-only telemetry wording, and the combined tree builds, prints mapbox 1.0.0 and passes the full suite and clippy. If the tag slips past the 22nd, just bump the heading date.