Skip to content

Bump to 0.3.0 - #179

Merged
sea-snake merged 1 commit into
mainfrom
claude/bump-crate-version-0-3-0-2w3uas
Sep 1, 2026
Merged

Bump to 0.3.0#179
sea-snake merged 1 commit into
mainfrom
claude/bump-crate-version-0-3-0-2w3uas

Conversation

@aterga

@aterga aterga commented Sep 1, 2026

Copy link
Copy Markdown
Collaborator

Summary

Bumps the workspace to 0.3.0. Version numbers only — no code changes.

A minor bump rather than a patch, because both the library API and the served
tool surface changed incompatibly since 0.2.0. The tool surface and the II
session engine moved out of imcp2 into a new sibling crate, imcp2-core
(#150, #157), which imcp2 now depends on by version; IcTools is gone, split
into IcCanisterTools and IcProtocolTools (#157). What an MCP client sees
changed too: only the app/canister tools are served (#158), state-changing calls
reach only applications that publish a service declaration (#166), the ledger
transfer/approval methods are refused (#154, #163), icp_top_up_canister is
instructions-only (#153), and routine replies no longer echo the per-app
principal (#177).

Under cargo's 0.x rules 0.2 is the compatibility range, so shipping this as
0.2.1 would hand the break to everyone on imcp2 = "0.2" — the requirement the
README recommends — the next time they ran cargo update. 0.3.0 opens a new
range instead.

Related issues

None. Groundwork for the v0.3.0 crates.io release, together with #180.

Changes

  • Cargo.toml, crates/imcp2-core/Cargo.toml, crates/imcp2-local/Cargo.toml: version0.3.0.
  • Cargo.toml: the [workspace.dependencies] pin follows — imcp2-core = { path = …, version = "0.3.0" }. It has to name the same number or the path dependency stops resolving.
  • README.md: the dependency line moves to imcp2 = "0.3"; "0.2" would no longer resolve to a current release.
  • Cargo.lock: regenerated with cargo update --workspace. Only the three workspace versions change; no dependency churn.

imcp2-core bumps in lockstep because publish-crate.yml checks the tag
against both manifests. imcp2-local moves with them: it releases on its own
imcp2-local-v* tags and has never been cut, so nothing holds it back, and its
--version would otherwise report 0.2.0 from a 0.3.0 tree.

Release notes

Two things stood between this commit and a published 0.3.0 when it was opened.
Both are now resolved:

  • The stale v0.3.0 tag has been deleted. It pointed at f350f96, where the manifests still said 0.2.0, so its publish run failed after 10s at the Check the tag matches both Cargo.toml versions guard. Nothing reached crates.io, so 0.3.0 is still free.
  • The verify job's packaging rehearsal is fixed by Publish the workspace in one cargo invocation, not crate by crate #180, merged. It ran cargo package --locked --no-verify -p imcp2, which resolves imcp2-core = "^0.3.0" against crates.io — where only 0.2.0 exists, because the new version is uploaded by the publish job that verify gates. verify now runs cargo publish --locked --dry-run --workspace, which resolves the two crates together.

So once this lands: tag v0.3.0 on the merge commit, push it, and approve the
release environment gate; imcp2-core uploads first, then imcp2.

One pre-flight check no workflow file can make: whether imcp2-core has a
trusted publisher configured on crates.io against this
repository/workflow/release environment. It has only ever been hand-published,
so if it was never set up, its upload 403s — after the tag is already spent.

Testing

  • cargo build --locked --workspace --all-targets — clean
  • cargo test --locked --workspace --all-targets — all pass
  • cargo clippy --locked --workspace --all-targets — exits 0; the 6 imcp2-core lints are pre-existing on main (this diff touches no .rs files)
  • cargo publish --locked --dry-run -p imcp2-core — passes at 0.3.0
  • cargo publish --locked --dry-run --workspace — passes at 0.3.0; this is what verify runs after Publish the workspace in one cargo invocation, not crate by crate #180
  • cargo fmt --all -- --check — differs, pre-existing and untouched here: the tree is formatted at a non-default line width, and CI does not gate it
  • npm test --prefix monitoring/mcp-status — not applicable, dashboard unchanged

The --locked runs are the meaningful ones for a version bump: they confirm
Cargo.lock agrees with the new manifests, which is what CI gates on.

Checklist

  • I have read the Contributing guidelines.
  • Docs updated for the user-visible change — the README dependency line.
  • No secrets, credentials, or internal-only information are included.

🤖 Generated with Claude Code

https://claude.ai/code/session_01GqhkbpCwxs67F5E2EzyDwh

A minor bump rather than a patch, because both the library API and the
served tool surface changed incompatibly since 0.2.0.

`imcp2` no longer contains the tool surface and the II session engine: they
moved to a new sibling crate, `imcp2-core` (#150, #157), which `imcp2` now
depends on by version and which publishes alongside it. The re-exports in
`src/lib.rs` keep the familiar names resolving (`IiInstance`,
`SessionGauges`, `Agent`, `IC_URL`), but the crate an embedder links has
changed shape, and `IcTools` is gone — split into `IcCanisterTools` and
`IcProtocolTools` (#157).

The surface an MCP client sees changed too: only the app/canister tools are
served (#158), state-changing calls now reach only applications that publish
a service declaration (#166), the ledger transfer/approval methods are
refused (#154, #163), `icp_top_up_canister` is instructions-only (#153), and
routine replies no longer echo the per-app principal (#177).

Under cargo's 0.x rules `0.2` is the compatibility range, so shipping this
as 0.2.1 would hand the break to everyone on `imcp2 = "0.2"` — the
requirement our own README recommends — the next time they ran
`cargo update`. 0.3.0 opens a new range instead; existing users stay on
0.2.x until they choose to move. The README's dependency line follows, as
`"0.2"` would no longer resolve to a current release.

`imcp2-core` moves in lockstep: publish-crate.yml checks the tag against
both manifests, and the workspace pin that binds them
(`imcp2-core = { path = …, version = … }`) has to name the same number or
the path dependency stops resolving. `imcp2-local` moves with them — it
releases on its own `imcp2-local-v*` tags and has never been cut, so there
is nothing to keep it behind, and its `--version` output would otherwise
report 0.2.0 from a 0.3.0 tree.

Co-authored-by: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GqhkbpCwxs67F5E2EzyDwh
@aterga
aterga requested a balanced review from Copilot September 1, 2026 16:28
@aterga
aterga marked this pull request as ready for review September 1, 2026 16:29
@aterga
aterga requested a review from a team September 1, 2026 16:29

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Bumps all workspace crates to the new incompatible 0.3 release line.

Changes:

  • Updates all crate versions and the imcp2-core workspace pin to 0.3.0.
  • Updates the README dependency example.
  • Synchronizes the lockfile package versions.

Reviewed changes

Copilot reviewed 4 out of 5 changed files in this pull request and generated no comments.

Show a summary per file
File Description
Cargo.toml Bumps imcp2 and its core dependency pin.
crates/imcp2-core/Cargo.toml Bumps imcp2-core.
crates/imcp2-local/Cargo.toml Bumps imcp2-local.
Cargo.lock Synchronizes workspace package versions.
README.md Recommends the 0.3 dependency line.

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

@sea-snake
sea-snake merged commit fa387f6 into main Sep 1, 2026
13 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants