chore(master): release 0.6.3 - #544
Conversation
Greptile SummaryUpdates the workspace release metadata to version 0.6.3.
Confidence Score: 5/5The release metadata update appears safe to merge. No blocking failure remains.
|
| Filename | Overview |
|---|---|
| Cargo.toml | Consistently updates the workspace version and internal path dependency constraints to 0.6.3. |
| Cargo.lock | Synchronizes workspace package lockfile versions with the 0.6.3 release. |
| .release-please-manifest.json | Advances the root release-please version from 0.6.2 to 0.6.3. |
| CHANGELOG.md | Adds the generated 0.6.3 release notes. |
Reviews (3): Last reviewed commit: "docs(release): add runtime materializati..." | Re-trigger Greptile
![pullfrog[bot]](https://avatars.githubusercontent.com/in/1768019?s=60&v=4){kind=small}
There was a problem hiding this comment.
✅ No new issues found. The bump is mechanically complete and consistent; one release-pipeline observation below for the maintainer, not a defect in this PR.
Reviewed changes — a release-please version bump with no behavioral surface, so the review focused on bump completeness, changelog fidelity, and whether the release pipeline actually ships everything this version contains.
- Version bump
0.6.2→0.6.3—workspace.package.versionplus all 45# x-release-please-version-annotated dep pins in the rootCargo.toml, and the"."entry in.release-please-manifest.json. Cargo.lockregeneration — 52 workspace crates rebumped; every changed line in the lock is aversion = "0.6.x"line, nothing else.CHANGELOG.md— new## [0.6.3]section inserted newest-first, covering 5feat(rpc), 2fix(rpc), and 4docsentries.
Verified:
- The 52 crates bumped in
Cargo.lockmatch exactly the workspace members usingversion.workspace = true. No stale0.6.2remains anywhere in the repo — the only repo-wide hits are the coincidentally-versioned third-partyblock2/writeableandNOTICE.md. - The independently-versioned crates are correctly left alone:
arcbox-hv(0.3.20),arcbox-helper(1.0.2),arcbox-fleet-agent(0.1.3), and"fleet": "0.1.3"in the manifest. - The changelog covers exactly the 11 commits between the 0.6.2 release commit (
08ad1da2) andb8d4057e, and thev0.6.2...v0.6.3compare link is right. - A patch bump carrying 5
featcommits is the configured behavior, not an error:release-please-config.jsonsets bothbump-minor-pre-majorandbump-patch-for-minor-pre-major, sofeatbumps patch on a 0.x line. git diff 08ad1da2...master -- '*/Cargo.toml'is empty, so no new crates or dependencies landed since 0.6.2 — the publish graph invariant (no publishable crate depending on apublish = falsecrate) is untouched.- The new
errors.proto/template.prototypes are reachable from the published crate: they land inarcbox.sandbox.v1, whichrpc/arcbox-protocol/src/lib.rs:41re-exports wholesale assandbox_v1. - The second commit (
chore: update Cargo.lock for release) is not a manual fixup —release-please.ymlregenerates and commits the lock on every open release PR so the release tag builds with--locked.
ℹ️ Tagging v0.6.3 will not refresh the buf.build/arcboxlabs/sandbox module
rpc/arcbox-protocol/proto/buf.yaml names the sandbox module for the Buf registry and states it "is published to the registry so SDK authors consume it by reference instead of vendoring a file out of this repo (CORE-53)". No step in this repo runs buf push — buf appears only in ci.yml's breaking-change gate. This release is the one landing the entire template / errors surface, so if the BSR module is the intended SDK-author entry point it is the release most worth pushing.
Technical details
# Sandbox proto module is registry-named but never pushed on release
## Affected sites
- `rpc/arcbox-protocol/proto/buf.yaml` — second module carries `name: buf.build/arcboxlabs/sandbox` and the header comment asserts, present tense, that the package "is published to the registry".
- `.github/workflows/release.yml` — jobs are `version`, `publish-crates`, `build-agent`, `package-and-release`, `linear-release`. None invokes `buf`.
- `.github/workflows/ci.yml:37-46,127-140` — the only `buf` usage in the repo, and it is the `buf breaking` gate, not a push.
## Required outcome
- The registry state for `buf.build/arcboxlabs/sandbox` and the repo's claim about it agree — either the release pipeline pushes the module on a `v*` tag, or the `buf.yaml` comment is reworded to describe how the module actually gets published.
## Open questions for the human
- Is the module pushed manually today, or deliberately deferred until the CORE-52 sandbox SDK redesign settles? If deferred, is it worth a note in `buf.yaml` so the present-tense claim does not read as an automated guarantee?
- If a push step is added, does it need to be gated so a `workflow_dispatch` binary rebuild does not republish (the way `publish-crates` already is)?Claude Opus ｜ 𝕏
1c8f545 to
5c34273
Compare
|
Run failed. View the logs →
|
b809855 to
f7ff6a8
Compare
There was a problem hiding this comment.
Important
The bump itself is still mechanically clean and the release pipeline will complete. But the regenerated changelog now silently omits the largest behavioral change in this release, and it advertises an SDK the tag does not publish. Both are worth settling before the tag is cut.
Reviewed changes — release-please force-pushed this branch after the TypeScript SDK work and two app fixes landed on master, so the review focused on what the regenerated release notes now claim versus what tagging v0.6.3 actually ships.
- Changelog regenerated from 11 entries to 28 — the
## [0.6.3]section picked up 6feat(sdk), 5fix(sdk),refactor/style/chore(sdk),test(e2e), andfix(migration)(#520) alongside the original rpc and docs entries. - Version target unchanged at
0.6.3—workspace.package.version, the 45# x-release-please-versiondep pins, and the"."manifest entry are identical to the previously reviewed bump;"fleet": "0.1.3"is still correctly untouched. Cargo.lockre-regenerated — 52 added and 52 removed lines, every one aversion = "0.6.x"line, nothing structural.
Re-verified at this head: the 52 bumped crates match the members using version.workspace = true; arcbox-hv (0.3.20), arcbox-helper (1.0.2) and arcbox-fleet-agent (0.1.3) are correctly left alone; a patch bump carrying 11 feat commits is the configured behavior (bump-minor-pre-major + bump-patch-for-minor-pre-major on a 0.x line); and the release pipeline's assumptions hold — cargo publish --workspace --exclude arcbox-hv --no-verify --locked is lock-consistent, no publishable crate gained a dependency on a publish = false member, and sdk/typescript is not a Cargo member so it never enters the publish graph.
⚠️ The release's largest change, #529, is absent from the 0.6.3 notes
9315eb87 "Materialize guest runtime on Btrfs (#529)" landed between 0.6.2 and this branch — 37 files, +1373/-375, including a new 706-line guest/arcbox-agent/src/runtime_materialize.rs, an assets.lock bump, and reworked boot-asset provisioning. Its squash subject is not a conventional-commit subject, so release-please skipped it entirely: grep -i btrfs CHANGELOG.md returns nothing in the 0.6.3 section, and the PR body that becomes the GitHub release has the same gap. Once the tag is cut, the published notes for the version that changes how guest runtime assets are materialized will mention only rpc, sdk, and docs work.
Technical details
# 0.6.3 release notes omit `9315eb87` (#529), including an agent-protocol semantics change
## Affected sites
- `CHANGELOG.md:8-65` (new `## [0.6.3]` section) — 28 entries, none of them `9315eb87`.
- PR #544 body — same generated content, so the GitHub release and the `linear-release`
job inherit the omission.
- `9315eb87` — subject `Materialize guest runtime on Btrfs (#529)` has no
`type(scope):` prefix, so release-please's `changelog-sections` matcher
(`release-please-config.json:8-20`) never classifies it. The four conventional
subjects that would have matched live in the squash *body*, where release-please
does not look.
- `common/arcbox-constants/src/wire.rs` — `9315eb87` redefined what
`AGENT_PROTOCOL_VERSION = 3` means (it now also requires the host-provided
`arcbox.runtime_generation` kernel parameter and Btrfs materialization) **without
bumping the number**. 0.6.2 already shipped `3` with the narrower
"sandbox Stop/Remove cleanup generation" meaning, and the constant's own doc comment
states a version must never be reused for a different meaning. `check_agent_protocol`
therefore cannot tell a 0.6.2-era agent from a 0.6.3 one, which is exactly the
scenario the omitted release note would have warned an operator about.
- `.github/workflows/` — no PR-title or commit-message lint anywhere, so nothing
prevented the non-conventional subject and nothing prevents a recurrence.
## Required outcome
- The published 0.6.3 notes describe the guest-runtime materialization change, or the
maintainers consciously decide it is not release-note-worthy.
- Future squash merges cannot silently fall out of the changelog.
## Suggested approach (optional)
- For this release: hand-add an entry to the `0.6.3` section and the PR body before
merging. Release-please only rewrites the section when a new commit lands on master,
so an edit made after the last master commit survives to the tag.
- Going forward: a conventional-commit gate on the PR title (the repo squash-merges, so
the PR title becomes the commit subject) closes the hole for good.
## Open questions for the human
- Is the reuse of `AGENT_PROTOCOL_VERSION = 3` for the expanded contract deliberate? If
a 0.6.2 daemon can ever meet a 0.6.3 agent (or the reverse) outside the
daemon-stages-its-own-agent path, the handshake will accept an incompatible pair.
- Does the Linear release record (`linear-release` job) get its notes from this
changelog? If so, the omission propagates there too.ℹ️ 15 SDK entries ship under 0.6.3, but tagging v0.6.3 publishes no SDK
The 0.6.3 section credits the entire @arcbox/sandbox TypeScript SDK — entry point, transport, data-plane namespaces, generated wire types, e2e gate. But sdk/typescript/package.json is at 0.1.0, release-please-config.json tracks only the "." and "fleet" packages, and .github/workflows/release.yml has no npm publish step. So a reader of the 0.6.3 notes sees a shipped SDK, while npm still has nothing (or 0.1.0) and the version numbers on the two artifacts have no relationship to each other.
Technical details
# SDK commits are versioned into the Rust release but the npm package is not released
## Affected sites
- `CHANGELOG.md:8-65` — 15 `sdk`-scoped entries under `## [0.6.3]`.
- `sdk/typescript/package.json:2-3` — `@arcbox/sandbox`, `"version": "0.1.0"`, and no
`private: true`, so it reads as intended-to-publish.
- `release-please-config.json:21-43` — `packages` has only `"."` and `"fleet"`. The
`"."` package's `exclude-paths` is `["fleet"]`, so `sdk/` commits are attributed to
the Rust workspace version.
- `.github/workflows/release.yml` — jobs are `version`, `publish-crates`, `build-agent`,
`package-and-release`, `linear-release`. No npm/node publish step.
## Required outcome
- The 0.6.3 notes and the artifacts a `v0.6.3` tag produces agree about whether the SDK
is part of this release.
## Suggested approach (optional)
- If the SDK should version independently: add an `sdk/typescript` package to
`release-please-config.json` (with `include-component-in-tag`, as `fleet` does) and
`exclude-paths: ["fleet", "sdk"]` on `"."`, so SDK commits stop landing in the Rust
changelog.
- If it should ride the workspace version: align `package.json` to `0.6.3` via
`extra-files` and add an npm publish job gated the same way `publish-crates` is
(`github.event_name == 'push'`, so a manual rebuild cannot republish).
## Open questions for the human
- Is `@arcbox/sandbox` deliberately unpublished until the CORE-52 redesign settles? If
so, `private: true` on the package would make that explicit and stop the notes from
implying otherwise.Claude Opus ｜ 𝕏
There was a problem hiding this comment.
Important
The #529 changelog entry is in and correctly formed. One half of the gap remains: the same line is missing from this PR's body, and the body — not CHANGELOG.md — is what release-please turns into the GitHub Release notes.
Reviewed changes — one commit since the last review, adding the release note that the previous review found missing.
- Added the
#529Features entry —* **runtime:** materialize guest runtime on Btrfs ([#529](...)) ([9315eb8](...)), placed in scope-alphabetical order between therpcandsdkentries and formatted exactly like a release-please-generated line. Nothing else changed;Cargo.lock,Cargo.toml, and the manifest are untouched by this commit.
⚠️ The GitHub Release body comes from the PR body, which still omits #529
Release-please does not read CHANGELOG.md when it cuts the release: on merge it runs PullRequestBody.parse() over the merged release PR's body and uses those parsed notes as the GitHub Release body. This PR's body still has no runtime entry, so the published 0.6.3 release notes — and the linear-release job, which links straight to that release page — will still omit the guest-runtime materialization work even though the repo's CHANGELOG.md now records it. Adding the identical line to the PR body's ### Features block closes it.
Technical details
# `CHANGELOG.md` and the PR body are two separate release-notes surfaces
## Affected sites
- `CHANGELOG.md:21` — the `runtime` entry added by `c16e41f1`. Correct, and it is the
surface a reader of the repo sees.
- PR #544 body, `### Features` block — no `runtime` entry. This is the surface
release-please serializes into the GitHub Release. Reference:
https://github.com/googleapis/release-please/blob/main/docs/design.md — "the pull
request body ... includes the changelog notes that will be included in the GitHub
release", and on merge release-please "tags the SHA of the pull request's merge commit
and uses the parsed release notes as the GitHub release's body".
- `.github/workflows/release.yml:347-363` — `linear-release` passes only
`version` and a link to `releases/tag/<version>`, so Linear inherits whatever the
GitHub Release body ends up saying.
## Required outcome
- The GitHub Release for `v0.6.3` mentions the guest-runtime materialization change, so
the repo changelog and the published release notes do not disagree.
## Suggested approach (optional)
- Paste the same line into the PR body's `### Features` list, in the same
scope-alphabetical position it occupies in `CHANGELOG.md`. Note that release-please
overwrites the body whenever it refreshes the PR, so make this edit after the last
commit lands on `master` — the same timing constraint the `CHANGELOG.md` edit had.Claude Opus ｜ 𝕏
|
🤖 Created releases: 🌻 |
1 participant
🤖 I have created a release beep boop
0.6.3 (2026-08-03)
Features
Bug Fixes
Code Refactoring
Tests
Documentation
Styles
Miscellaneous Chores
This PR was generated with Release Please. See documentation.