Repository navigation
chore(master): release 0.11.0 - #759
Conversation
 [Medium impact] The PR appears safe to merge, with the existing non-blocking release-note concern still open. Findings
SummaryPrepares the root release for
Reviews (22) · Last reviewed commit: "chore: update lockfiles for release" · Reviewed by Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
![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.
Reviewed changes
This run reviewed the generated root release PR for 0.11.0 — release-please's version bump plus the lockfile-update commit. Verified: the changelog range is complete for the root component, every workspace member's Cargo.lock block matches its manifest, and no annotated pin was missed.
.release-please-manifest.json— root version bumped 0.10.5 → 0.11.0;runner(0.1.7),sdk/typescript(0.1.6),sdk/python(0.1.4) untouched.CHANGELOG.md— new 0.11.0 section: tworefactorentries (restore the archived Fleet agent; rename Fleet to ArcBox Runners, flagged as breaking) and twodocsentries. All four commit links check out and each scope matches the paths its commit touched.Cargo.toml—[workspace.package]and everyx-release-please-version-annotated internal dependency pin bumped to 0.11.0;arcbox-hv(0.3.20) andarcbox-helper(1.1.0) correctly left at their manual-cadence versions.Cargo.lock— every changed line is a version bump; acargo metadata --no-depscross-check found zero lock↔manifest mismatches.
Range completeness: five commits landed on master since 0.10.5. Four are changelogged here. The fifth, 76c464e8 (fix(runner-agent)), touches only runner/arcbox-runner-agent/src/docker.rs, so release-please attributes it to the runner component — it rides in the companion PR #758 (release runner-agent 0.2.0). Nothing is missing from this release. Since both PRs touch Cargo.lock, merging either will trigger release-please to regenerate the survivor's branch and lock, so expect the other PR's diff to be re-cut after the first merge.
glm-5.3-flash ｜ 𝕏
300d304 to
8a0625c
Compare
There was a problem hiding this comment.
✅ No new issues found.
Reviewed changes
This run re-reviewed the re-cut release branch: since the prior pullfrog review (head 300d304), release-please regenerated the PR on top of master 7829cc2, and the only net change is the 0.11.0 CHANGELOG.md section — the manifest, Cargo.toml, and Cargo.lock regions are identical to the previously approved state.
- Expanded the 0.11.0 changelog — added two
feat(splicetcp), onetest(splicetcp), and onefix(build)entry for the commits that landed on master after the branch was first cut; release date moved to 2026-10-26. - Confirmed the release range —
v0.10.5..masteris exactly 9 commits, all accounted for: 8 in this changelog plus76c464e8(fix(runner-agent)), which rides in the companion PR #758. Each new entry's scope matches its commit's touched paths, andsplicetcp(common/splicetcp) is correctly attributed to the root component. - Re-ran the lock↔manifest cross-check —
cargo metadata --no-deps --offlineshows zero mismatches across all 68 workspace members; version arithmetic stays consistent (the newfeatcommits force a minor bump, already satisfied by the breaking runner rename).
glm-5.3-flash ｜ 𝕏
630f6be to
02a9e39
Compare
There was a problem hiding this comment.
✅ No new issues found.
Reviewed changes
This run re-reviewed the release PR after it was re-cut on top of master a13f5c57 — the first merge commit in the repo's master history, importing a 34-commit IPv6/splicetcp branch. That grew the 0.11.0 range from 10 to 44 commits; the checks from the prior review were re-run against the new head, and the delta is two changelog entries plus one lockfile dependency edge.
- Added the
feat(net)merge entry and thefix(e2e)branch-tip entry to the 0.11.0 changelog — every commit on master's first-parent path is changelogged (9 root entries;76c464e8rides in the companion PR #758), and the merged branch is represented by its merge title and tip. Scope↔path checks pass for both new entries; no merged-branch commit touchesrunner/orsdk/. - Regenerated
Cargo.lockwith theetherparsedependency edge —arcbox-packet's manifest on master declaresetherparse = "0.21", and the lock'setherparse 0.21.0package block pre-existed, so the diff adds only the edge. - Re-ran the lock↔manifest cross-check —
cargo metadata --no-deps --offline: 65 members at 0.11.0, witharcbox-hv0.3.20,arcbox-helper1.1.0, andarcbox-runner-agent0.1.7 at their expected manual/component cadences; zero mismatches.Cargo.tomlpins, manifest, and version arithmetic are identical to the previously approved state, and thedraft+force-tag-creationrelease config is untouched.
ℹ️ Release notes carry PR-level granularity for the merged IPv6 epic
The 0.11.0 range now contains the repo's first merge commit (a13f5c57), which imports the 34-commit IPv6 branch. The changelog lists the merge's PR title and the branch tip (6958d54d) but not the 33 internal commits — release-please walks commit history in reverse commit-date order and stops at the v0.10.5 release commit (2026-10-23 02:30 +0800), which is newer than every internal commit except the tip (04:45). Nothing is lost from the release itself: the tag diff contains all 44 commits, and re-cutting the branch reproduces this output deterministically, so there is nothing to change in this PR. If per-commit changelog detail is wanted for future work, that is a merge-style policy decision (squash-merges preserve one-commit granularity) — surfaced here because this is the first release range the behavior applies to.
Technical details
# Changelog omits internal commits of the first merge-commit range
## Affected sites
- CHANGELOG.md:26-43 — 0.11.0 section lists 10 entries; the release range contains 44 commits
- .github/workflows/release-please.yml — release-please-action@v4 → release-please ^17.3.0
## Required outcome
- No change required in this PR. Recorded so the next merge-into-master release is reviewed against the correct expectation: release-please enumerates commits until the reverse-commit-date walk reaches the last release commit, so branch commits older than that commit are summarized by their PR's merge title only.
## Open questions for the human (optional)
- Decide merge style for future feature branches: squash-merge keeps one-changelog-entry-per-PR granularity (current output already matches that); merge-commit style truncates old-dated internal commits from the changelog.glm-5.3-flash ｜ 𝕏
4a4b66d to
3f315f1
Compare
There was a problem hiding this comment.
✅ No new issues found.
Reviewed changes
This run re-reviewed the re-cut release branch: since the prior pullfrog review (head 4a4b66d), ce82383 (fix(splicetcp), the squash-merge of PR #760) landed on master and release-please regenerated the PR on top of it. The delta is one changelog entry plus the lockfile-update commit — the manifest and Cargo.toml regions are identical to the previously approved state.
- Added the
fix(splicetcp): preserve recovery during host-first close (#760)entry to the 0.11.0 changelog and moved the release date to 2026-10-27 — the release commit's parent isce82383d, exactly master's current head, so the range stays complete: every commit release-please walks is changelogged,76c464e8(fix(runner-agent)) still rides in the companion PR #758, and the 33 internal IPv6-branch commits remain summarized by thefeat(net)merge entry. The commit touchescommon/splicetcp,.github/workflows, andvirt/arcbox-vm-agent— norunner/orsdk/paths, so nothing needs re-attribution. Note it is a squash-merge that also bundles a CI toolchain-components fix and avm-agentcast fix under the one title — release-please-generated output, nothing to change here. - Regenerated
Cargo.lock— every changed line is one of the 65 workspace-member version bumps already verified in the prior cut (itertools/regressstill showing 0.10.5 are third-party crates at coincidentally equal versions, not members); theetherparseedge forarcbox-packetis unchanged context in this diff. - Re-ran the lock↔manifest cross-check —
cargo metadata --no-deps --offline: 65 members at 0.11.0 witharcbox-hv0.3.20,arcbox-helper1.1.0, andarcbox-runner-agent0.1.7 at their expected manual/component cadences; zero mismatches. No0.10.5pins remain inCargo.toml, and the release config (draft+force-tag-creation) is untouched.
glm-5.3-flash ｜ 𝕏
9f4f16d to
d7791f8
Compare
There was a problem hiding this comment.
✅ No new issues found.
Reviewed changes
This run re-reviewed the re-cut release branch: since the prior pullfrog review (head 9f4f16d), 3ff31a0 (docs(splicetcp)) landed on master and release-please regenerated the PR on top of it. The delta is one changelog entry plus the lockfile-update commit — the manifest and Cargo.toml regions are identical to the previously approved state.
- Added the
docs(splicetcp): describe discard retention without product references (3ff31a0)entry to the 0.11.0 Documentation section and moved the release date to 2026-10-29 — the commit touches onlycommon/splicetcp/README.md, so root-component attribution and scope are correct. The release commit's parent is master's current head, so the range stays complete: 13 first-parent commits, 12 changelogged here, and76c464e8(fix(runner-agent)) still rides in the companion PR #758. - Regenerated
Cargo.lock— every changed line is one of the 65 workspace-member version bumps already verified in the prior cut (itertools/regressstill showing 0.10.5 are third-party crates at coincidentally equal versions, not members). - Re-ran the lock↔manifest cross-check —
cargo metadata --no-deps --offline: 65 members at 0.11.0 witharcbox-hv0.3.20,arcbox-helper1.1.0, andarcbox-runner-agent0.1.7 at their expected manual/component cadences; zero mismatches. No0.10.5pins remain inCargo.toml, and the diff touches only the four release files — the release config (draft+force-tag-creation) is untouched.
glm-5.3-flash ｜ 𝕏
3034b4b to
aedd0b1
Compare
There was a problem hiding this comment.
✅ No new issues found.
Reviewed changes
This run re-reviewed the re-cut release branch: since the prior pullfrog review (head 3034b4b), master gained two merge integrations (f810551 fix/guest-cpu-accounting, 123f785 refactor/keychain-ca) and f4b6a83 (test(daemon)), and release-please re-cut the PR on top of the new master head. The delta is one changelog entry plus master's flow-through into the release files; the manifest and the 65 member version bumps are identical to the previously approved state.
- Added the
test(daemon): build test runtimes without system proxy probes (f4b6a83)entry to the 0.11.0 Tests section and moved the release date to 2026-10-30 — the commit touchesapp/arcbox-daemontest files plusapp/arcbox-core'sConfig::for_testtest-support export, so root-component attribution and scope are correct. The release commit's parent is master's current head, so the range stays current: 16 first-parent commits, 13 changelogged,76c464e8still rides in companion PR #758, and neither merge touchesrunner/orsdk/. - Flow-through of the keychain-ca integration —
arcbox-helpermoves 1.1.0 → 1.2.0 (its manual-cadence bump, landed via the merge), and the regeneratedCargo.lockpicks up the merged dependency edges (helper now consumesarcbox-local-cafrom the workspace). Member manifest, root pin, and lock block all agree at 1.2.0. - Re-ran the lock↔manifest cross-check —
cargo metadata --no-deps --offline: exactlyarcbox-hv0.3.20,arcbox-helper1.2.0, andarcbox-runner-agent0.1.7 off the 0.11.0 version, zero mismatches; the lock diff is 65 member version bumps with no third-party drift (itertools/regressat 0.10.5 remain the benign coincidence). No0.10.5pins remain inCargo.toml, and the release config (draft+force-tag-creation) is untouched.
ℹ️ The two new merge integrations are invisible in the 0.11.0 changelog
The 0.11.0 range grew to 16 first-parent commits, but f810551 and 123f785 are titled merge: integrate … — the merge: type is not a conventional-commit type, so release-please generates no entries for the titles, and their branch tips (dated 2026-10-09 and 2026-10-11) predate the v0.10.5 release-commit cutoff that truncates the changelog walk. Unlike the IPv6 epic (whose merge carried a conventional feat(net): title and was represented), both integrated changes are entirely absent from 0.11.0's release notes while shipping in the release: the machine CPU-stats fix (guest/guest_nice double-counting) and the whole keychain-ca batch (Keychain-backed local CA, HTTPS web services, guest certificate signing, arcbox-helper 1.2.0).
Nothing in this PR can fix it — the changelog is generated (hand edits would be overwritten on the next re-cut) and the merge commits are already on master — so this is recorded, not blocked. For the next merge-to-master integration, title the merge commit with a conventional type and scope (as a13f5c57 did) or squash-merge the branch, so integrated work always surfaces in release notes.
Technical details
# 0.11.0 changelog omits the two new merge integrations entirely
## Affected sites
- CHANGELOG.md:8-46 — 0.11.0 section lists 13 entries; the release range contains 16 first-parent commits, two of which (`f810551`, `123f785`) produce no entry at all
- Merge commits f8105518/123f785f — `merge: integrate …` titles are not conventional-commit types; branch tips 95feae4b (2026-10-09) and 504a0127 (2026-10-11) predate the v0.10.5 release-commit date cutoff (2026-10-23 02:30 +0800), so their internal commits are truncated
## Required outcome
- No change in this PR (generated file; merges already on master). Future integrations must be representable: conventional-typed merge titles or squash-merges.
## Suggested approach (optional)
- Follow the IPv6 epic's pattern: merge commit `a13f5c57` titled `feat(net): integrate IPv6 lifecycle with silent TCP rejection` produced a changelog entry even though its internal commits were truncated. The `merge:` type produces nothing.
## Open questions for the human (optional)
- Decide the merge-style policy for feature branches: conventional-typed merge commits vs squash-merge, so integrated work always reaches the changelog.glm-5.3-flash ｜ 𝕏
807fb82 to
f13fd33
Compare
There was a problem hiding this comment.
✅ No new issues found.
Reviewed changes
This run re-reviewed the re-cut release branch: since the prior pullfrog review (head 807fb82), master gained 98c99fb (docs(charter)), e130e01 (docs(agents)), 26ffceb (refactor(virt): remove the consumerless arcbox-net-virtio crate), and cd19fe7 (refactor(core): drop the engine and image compatibility re-exports), and release-please regenerated the PR on top of the new head. The delta is four changelog entries plus the member-count flow-through in the release files; the manifest, version pins, and release config are identical to the previously approved state.
- Added the four new entries to the 0.11.0 changelog and re-cut the branch on master's head — the release commit's parent is exactly master's current tip (
cd19fe7), so the range stays current: 20 first-parent commits sincev0.10.5, 17 changelogged,76c464e8(fix(runner-agent)) still rides in the companion PR #758, and the twomerge:-typed integrations remain omitted (unchanged from the prior review's observation). Scope↔path and SHA-link checks pass for all four entries; none touchrunner/orsdk/. - Flow-through of the
arcbox-net-virtioremoval (26ffceb) — the crate directory is gone, no workspace pin or lock block remains, and the workspace member count drops 68 → 67; the branch diff carries noarcbox-net-virtiolines because master's base already reflects the removal. - Re-ran the lock↔manifest cross-check —
cargo metadata --no-deps --offline: 67 packages, 64 at 0.11.0, witharcbox-hv0.3.20,arcbox-helper1.2.0, andarcbox-runner-agent0.1.7 at their expected manual/component cadences; zero mismatches. No0.10.5pins remain inCargo.toml, the lock diff is member version bumps only with no third-party drift, and the diff touches only the four release files (draft+force-tag-creationuntouched).
glm-5.3-flash ｜ 𝕏
a319b9c to
cc79f04
Compare
There was a problem hiding this comment.
✅ No new issues found.
Reviewed changes
This run re-reviewed the re-cut release branch: since the prior pullfrog review (head a319b9c), master gained cf6c37d (fix(docker)) and release-please regenerated the PR on top of it. The delta is one changelog entry plus the regenerated lockfile commit — the manifest and Cargo.toml regions are identical to the previously approved state.
- Added the
fix(docker): retry container archive and start requests on a busy overlay (cf6c37d)entry to the 0.11.0 Bug Fixes and re-cut the branch on master's tip — the release commit's parent is exactly master's current head (cf6c37d), so the range stays complete: 21 first-parent commits sincev0.10.5, 18 changelogged,76c464e8(fix(runner-agent)) still rides in the companion PR #758 (still open), and the twomerge:-typed integrations remain omitted (unchanged observation from the prior review). The commit touches onlyapp/arcbox-docker/+docs/, so thedockerscope and root-component attribution are correct, and the changelog's SHA link matches the commit's full hash. - Regenerated the lockfile commit — the range-diff against the prior cut shows only the changelog hunk; the lockfile patch content, manifest (root at
0.11.0,runner/sdkentries untouched), andCargo.tomlpins are identical to the previously approved state. - Re-ran the lock↔manifest cross-check —
cargo metadata --no-deps --offline: 67 members, 64 at 0.11.0, witharcbox-hv0.3.20,arcbox-helper1.2.0, andarcbox-runner-agent0.1.7 at their expected manual/component cadences; zero mismatches, and the release config (draft+force-tag-creation) is untouched.
glm-5.3-flash ｜ 𝕏
6b65b6a to
60f19b8
Compare
There was a problem hiding this comment.
✅ No new issues found.
Reviewed changes
This run re-reviewed the re-cut release branch: since the prior pullfrog review (head 6b65b6a), master gained 7e9b711 (test(engine): accept a reset when the client closes on a bad acknowledgement) and release-please regenerated the PR on top of it. The delta is one changelog entry plus the regenerated lockfile commit — the range-diff against the prior cut shows only the changelog hunk; the manifest, Cargo.toml pins, and lockfile patch content are identical to the previously approved state.
- Added the
test(engine): accept a reset when the client closes on a bad acknowledgement (7e9b711)entry to the 0.11.0 Tests section — the commit touches onlyengine/arcbox-engine/src/agent_client/instance_authority/tests.rs(a test-only assertion relaxation that also acceptsConnection reseton Linux), so root-component attribution and scope are correct. The release commit's parent is exactly master's current head, so the range stays complete: 22 first-parent commits sincev0.10.5— 19 changelogged (20 bullets, since1c544b7appears in both BREAKING CHANGES and Code Refactoring),76c464e8(fix(runner-agent)) still rides in the companion PR #758 (still open), and the twomerge:-typed integrations remain omitted (unchanged observation from the prior review). - Regenerated the lockfile commit — the lockfile patch content, manifest (root at
0.11.0,runner/sdkentries untouched), andCargo.tomlpins are identical to the previously approved state; no third-party drift. - Re-ran the lock↔manifest cross-check —
cargo metadata --no-deps --offline: 67 members, 64 at 0.11.0, witharcbox-hv0.3.20,arcbox-helper1.2.0, andarcbox-runner-agent0.1.7 at their expected manual/component cadences; zero mismatches, and the release config (draft+force-tag-creation) is untouched.
glm-5.3-flash ｜ 𝕏
944190f to
cc7e263
Compare
There was a problem hiding this comment.
✅ No new issues found.
Reviewed changes
This run re-reviewed the re-cut release branch: since the prior pullfrog review (head 6b65b6a), master gained 7e9b711 (test(engine)) and 9054214 (docs(architecture)), and release-please regenerated the PR on top of the new head. The delta is two changelog entries plus the regenerated lockfile commit — the manifest, Cargo.toml pins, and lockfile patch content are identical to the previously approved state. (7e9b711 was already verified by the review at head 944190f; 9054214 is the only entry net-new since that review.)
- Added the
test(engine): accept a reset when the client closes on a bad acknowledgement (7e9b711)entry to the 0.11.0 Tests section and thedocs(architecture): add the R4 seam map and refresh the R4 gate (9054214)entry to Documentation, re-cutting the branch on master's tip — the release commit's parent is exactly master's current head (90542146), so the range stays complete: 23 first-parent commits sincev0.10.5— 20 changelogged (21 bullets, since1c544b7appears in both BREAKING CHANGES and Code Refactoring) — with76c464e8(fix(runner-agent)) still riding in the companion PR #758 (re-checked, still open) and the twomerge:-typed integrations remaining omitted (unchanged observation from the prior review, not re-raised). Scope↔path checks pass:7e9b711touches onlyengine/arcbox-engine/src/agent_client/instance_authority/tests.rsand90542146onlydocs/architecture/vm-stack-redesign.md, so both are root-component entries with correct scopes, and both changelog SHA links match the commits' full hashes. - Regenerated the lockfile commit — the range-diff against the prior cut shows only the changelog hunks; the manifest (root at
0.11.0,runner/sdkentries untouched),Cargo.tomlpins, and lockfile patch content are identical to the previously approved state, with no third-party drift. - Re-ran the lock↔manifest cross-check —
cargo metadata --no-deps --offline: 67 members, 64 at 0.11.0, witharcbox-hv0.3.20,arcbox-helper1.2.0, andarcbox-runner-agent0.1.7 at their expected manual/component cadences; zero mismatches, no0.10.5pins remain inCargo.toml, and the release config (draft+force-tag-creation) is untouched (the diff still touches only the four release files).
glm-5.3-flash ｜ 𝕏
b145224 to
9d2c3ce
Compare
There was a problem hiding this comment.
✅ No new issues found.
Reviewed changes
This run re-reviewed the re-cut release branch: since the prior pullfrog review (head b145224), master gained the 16-commit HV/VZ checkpoint and datapath-control series (fa94e11 … 8239e08), and release-please regenerated the PR on top of it. The delta is sixteen changelog entries plus the regenerated lockfile commit — the manifest, Cargo.toml pins, and lockfile patch content are identical to the previously approved state.
- Added the sixteen entries to the 0.11.0 changelog and re-cut the branch on master's tip — the release commit's parent is exactly master's current head (
8239e08), so the range stays complete: 45 first-parent commits sincev0.10.5— 42 changelogged (43 bullets, since1c544b7appears in both BREAKING CHANGES and Code Refactoring) — with76c464e8(fix(runner-agent)) still riding in the companion PR #758 (re-checked, still open) and the twomerge:-typed integrations remaining omitted (unchanged observation, not re-raised). All 16 new commits are non-merge; scope↔path checks pass (vmm/hv/vz/net/vsock/splicetcp/virtioeach match their commit's touched paths), none touchrunner/orsdk/, and all sixteen changelog SHA links resolve to the actual commits viagit rev-parse. - Regenerated the lockfile commit — the
Cargo.lockregion of the diff has exactly 130 changed lines, all memberversion =bumps (65 members × ±1), with no dependency edges and no third-party drift; the range-diff against the prior cut shows only the changelog hunk, so the lockfile patch content is identical to the previously approved state. - Re-ran the lock↔manifest cross-check —
cargo metadata --no-deps --offline: 68 members, exactlyarcbox-hv0.3.20,arcbox-helper1.2.0, andarcbox-runner-agent0.1.7 off the 0.11.0 version; zero mismatches, no0.10.5pins remain inCargo.toml, the working tree stayed clean after the check, and the release config (draft+force-tag-creation) is untouched — the diff still touches only the four release files.
glm-5.3-flash ｜ 𝕏
6fdbcbd to
87ec6da
Compare
There was a problem hiding this comment.
✅ No new issues found.
Reviewed changes
This run re-reviewed the re-cut release branch: since the prior pullfrog review (head 6fdbcbd), master gained 1ab3ab0 (fix(agent): link arcbox-transport on every target) and release-please regenerated the PR on top of it. The delta is one changelog entry plus the regenerated lockfile commit — the manifest, Cargo.toml pins, and lockfile patch content are identical to the previously approved state.
- Added the
fix(agent): link arcbox-transport on every target (1ab3ab0)entry to the 0.11.0 Bug Fixes and re-cut the branch on master's tip — the release commit's parent is exactly master's current head (1ab3ab0), so the range stays complete: 46 first-parent commits sincev0.10.5— 43 changelogged (44 bullets, since1c544b7appears in both BREAKING CHANGES and Code Refactoring) — with76c464e8(fix(runner-agent)) still riding in the companion PR #758 (re-checked, still open) and the twomerge:-typed integrations remaining omitted (unchanged observation, not re-raised). Scope↔path checks pass:1ab3ab0touches onlyguest/arcbox-agent/Cargo.toml(moving thearcbox-transportworkspace dep from the Linux-only target table into the unconditional[dependencies]), so theagentscope and root-component attribution are correct, it touches norunner/orsdk/paths, and the changelog SHA link matches the commit's full hash. - Regenerated the lockfile commit — the range-diff against the prior cut shows only the changelog hunk; the manifest (root at
0.11.0,runner/sdkentries untouched),Cargo.tomlpins, and lockfile patch content are identical to the previously approved state, with no third-party drift. - Re-ran the lock↔manifest cross-check —
cargo metadata --no-deps --offline: 68 members, exactlyarcbox-hv0.3.20,arcbox-helper1.2.0, andarcbox-runner-agent0.1.7 off the 0.11.0 version; zero mismatches, no0.10.5pins remain inCargo.toml, the working tree stayed clean after the check, and the release config (draft+force-tag-creation) is untouched — the diff still touches only the four release files.
glm-5.3-flash ｜ 𝕏
ba8d959 to
f86caf9
Compare
There was a problem hiding this comment.
✅ No new issues found.
Reviewed changes
This run re-reviewed the re-cut release branch: since the prior pullfrog review (head ba8d959), master gained 83a7c44 (feat(vmm): serve the VM driver port over HvMachine (R4b)), and release-please regenerated the PR on top of it. The delta is one changelog entry plus the regenerated release and lockfile commits — the manifest and Cargo.toml pins are identical to the previously approved state.
- Added the
feat(vmm): serve the VM driver port over HvMachine (R4b) (83a7c44)entry to the 0.11.0 Features and re-cut the branch on master's tip — the release commit's parent is exactly master's current head (83a7c44, confirmed againstorigin/master), so the range stays complete: the 46 first-parent master commits sincev0.10.5are fully accounted — 43 changelogged on the path (44 distinct entries including the merged IPv6 branch tip6958d54; 45 bullets, since1c544b7appears in both BREAKING CHANGES and Code Refactoring),76c464e(fix(runner-agent)) still riding in the companion PR #758 (re-checked, still open), and the twomerge:-typed integrations remaining omitted (unchanged observation, not re-raised). Scope↔path check passes:83a7c44touchesvirt/arcbox-vmmplus rootCargo.lockanddocs/architecture, so thevmmscope and root-component attribution are correct, it touches norunner/orsdk/paths, and the changelog SHA link matches the commit's full hash (83a7c440f619a91cb835372b7443c4299fdc01cd). The entry sits in correct alphabetical position among thevmmfeature bullets. - Flow-through of the base-side dependency change —
83a7c44adds macOS-target dependenciesarcbox-vm-driverandasync-traittovirt/arcbox-vmm(plus a macOS dev-dependency onarcbox-vm-driverwithtestkit) and two correspondingCargo.lockedges on master. These flow into the branch's lock as base-side context: the lockfile commit's own patch remains the 65 pure member version bumps (verified line-by-line in the diff's lockfile region — zero dep edges, no third-party drift), and the branch lock'sarcbox-vmmblock lists both new edges. - Re-ran the lock↔manifest cross-check —
cargo metadata --no-deps --offline: 68 members, exactlyarcbox-hv0.3.20,arcbox-helper1.2.0, andarcbox-runner-agent0.1.7 off the 0.11.0 version; zero mismatches, no0.10.5pins remain inCargo.toml, the working tree stayed clean after the check, and the release config (draft+force-tag-creation) is untouched — the diff still touches only the four release files.
glm-5.3-flash ｜ 𝕏
7380bed to
701baa8
Compare
|
Custom returned an error, so this run stopped. If it names your key, plan or balance, fix that with the provider or pick another model.
|
a827dd6 to
9ac432e
Compare
There was a problem hiding this comment.
✅ No new issues found.
Reviewed changes
This run re-reviewed the release branch after two more re-cuts onto master's moving tip: since the prior pullfrog review (head 7380bed), master gained the 9-commit no-virtualization-host series and the 18-commit vhost-user series, and release-please regenerated the PR on top of each — the release commit 9ac432e1's parent is exactly master's current head (bfc67f79). The delta is 27 changelog entries, the new arcbox-vhost-user workspace member's flow-through, and the regenerated release and lockfile commits.
- Added 27 new 0.11.0 changelog entries and moved the release date to 2026-11-02 — the 9 no-virtualization-host entries (
feat(api)hardware-virtualization reporting,feat(daemon)System-startup skip,feat(vmm)fail-fast,fix(api)/fix(daemon)startup handling,fix(fs)FUSE open flags,refactor(api)From-conversion,refactor(vmm)exhaustiveVmBackendmatch, docs log) and 18 vhost-user entries (10 features, 3 fixes, 4 tests, 1 doc). All 27 SHA links match the commits' full hashes, scope↔path checks pass for every entry, alphabetical placement within each section is correct, and none touchrunner/orsdk/. The release range stays complete: 73 first-parent commits sincev0.10.5— 70 changelogged,76c464e8(fix(runner-agent)) still riding in the companion PR #758 (re-checked, still open), and the twomerge:-typed integrations remaining omitted (unchanged observation, not re-raised). - Carried the new
arcbox-vhost-usermember through the release files — the vhost-user series addedvirt/arcbox-vhost-userto the workspace (crate-creation commit0041a642also updated rootCargo.toml/Cargo.lock); the root pin carries thex-release-please-versionannotation at 0.11.0 and the lock block resolves against its manifest. Member count is now 69. - Regenerated the release and lockfile commits — the lockfile commit is 66 insertions/66 deletions, every changed line a member
versionbump (65 prior members + the new one), zero dep edges, no third-party drift; the manifest (.at 0.11.0,runner/sdkentries untouched) andCargo.tomlpins are identical to the previously approved state apart from the new annotated pin. - Re-ran the lock↔manifest cross-check —
cargo metadata --no-deps --offline: 69 members, exactlyarcbox-hv0.3.20,arcbox-helper1.2.0, andarcbox-runner-agent0.1.7 off the 0.11.0 version; zero mismatches, no0.10.5pins remain inCargo.toml, and the release config (draft+force-tag-creation) is untouched — the diff still touches only the four release files.
glm-5.3-flash ｜ 𝕏
2bf9849 to
a103282
Compare
There was a problem hiding this comment.
✅ No new issues found.
Reviewed changes
This run re-reviewed the re-cut release branch: since the prior pullfrog review (head 2bf98493), master gained the 11-commit on-demand QEMU download series, and release-please regenerated the PR on top of it — the release commit a1032821's parent is exactly master's current head (1b77a887c), so the range stays complete. The delta is eleven changelog entries plus the regenerated release and lockfile commits.
- Added the 11 QEMU-download-series entries to the 0.11.0 changelog and re-cut the branch on master's tip —
feat(api),feat(asset),feat(cli),feat(daemon), fivefeat(image),test(bench)anddocsentries. All 11 SHA links resolve to the commits' full hashes, every scope matches its commit's touched paths (api→app/arcbox-api+rpc/,asset→common/arcbox-asset,cli→app/arcbox-cli,daemon→app/arcbox-daemon,image→engine/arcbox-image+assets.lock,bench→tests/bench/qemu-download), alphabetical placement within each section holds, and none touchrunner/orsdk/. Range completeness verified locally: 84 first-parent commits sincev0.10.5— 81 changelogged (82 distinct entries, 83 bullets with the1c544b7double) — with76c464e8(fix(runner-agent)) still riding in the companion PR #758 (re-checked, still open) and the twomerge:-typed integrations remaining omitted (recorded 2026-10-30, not re-raised). - Regenerated the release and lockfile commits — the lockfile commit
ee0b0101isCargo.lock-only at 66/66, and all 132 changed lines are memberversionbumps with zero dependency edges and no third-party drift; the manifest (.at 0.11.0,runner/sdkentries untouched) andCargo.tomlpins are identical to the previously approved state, no0.10.5pin remains inCargo.toml, and the diff still touches only the four release files (draft+force-tag-creationuntouched). - Re-ran the lock↔manifest cross-check —
cargo metadata --no-deps --offline: 69 members, exactlyarcbox-hv0.3.20,arcbox-helper1.2.0, andarcbox-runner-agent0.1.7 off the 0.11.0 version; zero mismatches (the lock'sitertools/regressat 0.10.5 remain the benign third-party coincidence).
ℹ️ 0.11.0 ships the QEMU machinery with the build pin still empty
The new [qemu] pin in assets.lock names version 0.1.0 but carries an empty arch.arm64.sha256, and the CDN returns 404 for qemu-darwin-arm64-v0.1.0.tar.gz — the two agree. Per the pin's own header and the docs log, an empty SHA-256 means nothing is downloaded and the daemon behaves as before, so the on-demand download feature this release changelogs is dormant until arcboxlabs/qemu v0.1.0 is signed, notarized and published and the pin is filled. Nothing in this PR can or should change — recorded so release consumers on no-virtualization Macs know QEMU is not actually available in 0.11.0, and so the next run expects a pin-fill commit on master (which will re-cut this branch if it lands before merge).
Technical details
# 0.11.0 ships the QEMU machinery with the build pin still empty
## Affected sites
- assets.lock:30-33 — `[qemu]` sets `version = "0.1.0"` but `arch.arm64.sha256` is empty
- docs/logs/2026-11-02-qemu-on-demand-download.md:76-84 — "Follow-ups" lists the pin fill for when the build is published
## Required outcome
- No change in this PR (generated release files; the pin fill is a deliberate follow-up on master once `arcboxlabs/qemu` v0.1.0 is signed, notarized and published — the CDN currently 404s for both arch variants, matching the empty pin).
## Open questions for the human (optional)
- None — informational only: release consumers on no-virtualization Macs get the machinery but no QEMU in 0.11.0; a pin-fill commit on master will re-cut this branch if it lands before merge.glm-5.3-flash ｜ 𝕏
ee0b010 to
5625aaa
Compare
There was a problem hiding this comment.
✅ No new issues found.
Reviewed changes
This run re-reviewed the re-cut release branch: since the prior pullfrog review (head ee0b0101), master gained 7d4f3ce (fix(daemon)), 93c272f (fix(vmm)), and d93903b (docs), and release-please regenerated the PR on top of the new head — the release commit 5625aaad's parent is exactly master's current tip (d93903b), so the range stays complete. The delta is three changelog entries plus the regenerated release and lockfile commits.
- Added the three new entries to the 0.11.0 changelog and moved the release date to 2026-11-03 —
fix(daemon): raise the open-file soft limit at startup (7d4f3ce)andfix(vmm): stop capping HV vsock connections at 64 descriptors (93c272f)in Bug Fixes, plusdocs: record the daemon open-file limit fix (d93903b)in Documentation. All three SHA links match the commits' full hashes, scope↔path checks pass (daemon→app/arcbox-daemon+docs/daemon-lifecycle.md,vmm→virt/arcbox-vmm+docs/architecture/hv-backend.md, docs →docs/+tests/bench/), alphabetical placement within each section holds, and none touchrunner/orsdk/. Range completeness verified locally:1b77a887c..origin/mastercontains exactly those three commits. - Regenerated the release and lockfile commits — the lockfile commit
feee0daremainsCargo.lock-only, and every changed line in its region is a memberversionbump with zero dependency edges (none of the three master commits touched aCargo.toml) and no third-party drift; the manifest (.at 0.11.0,runner/sdkentries untouched) andCargo.tomlpins are identical to the previously approved state — the manual-cadencearcbox-hv0.3.20 andarcbox-helper1.2.0 pins stay untouched, and no0.10.5pin remains. - Re-ran the lock↔manifest cross-check —
cargo metadata --no-deps --offline: 69 members, exactlyarcbox-hv0.3.20,arcbox-helper1.2.0, andarcbox-runner-agent0.1.7 off the 0.11.0 version; zero mismatches, and the release config (draft+force-tag-creation) is untouched — the diff still touches only the four release files. - Re-checked the companion PR #758 — still open (
autorelease: pending); when it merges, this branch will be re-cut with a lockfile delta. The twomerge:-typed integrations and the dormant[qemu]pin remain as recorded on 2026-10-30 / 2026-11-02 — not re-raised.
glm-5.3-flash ｜ 𝕏
feee0da to
4728ed8
Compare
There was a problem hiding this comment.
✅ No new issues found.
Reviewed changes
This run re-reviewed the re-cut release branch: since the prior pullfrog review (head feee0da), master gained 12 commits (the vhost-user FsServer/QEMU-System-VM-probe series, two fs fixes, and the build(fs) dependency cleanup) and release-please regenerated the PR on top of the new head — the release commit 4728ed89's parent is exactly master's current tip (e97ddc8), so the range stays complete. The delta is twelve changelog entries (one of them in a new Build System section) plus the regenerated release and lockfile commits.
- Added the twelve entries to the 0.11.0 changelog and re-cut the branch on master's tip —
feat(vhost-user): serve virtio-fs shares through FsServer (224e87d), sixtest(vhost-user)entries for the QEMU System VM probe series (b74ce68,a3e5e5f,393105d,9039d61,5101d1e,7fb9ee1),fix(fs): cap the read size a guest asks for (6a18210),fix(fs): release a FUSE session's files and inodes when it ends (1d41796),fix(vhost-user): refuse virtio-fs requests longer than any FUSE request (b079209),docs: record vhost-user-fs with the real System VM agent (8b0898b), and a new Build System section carryingbuild(fs): depend on the fs and core VirtIO crates, not the umbrella (e97ddc8). All 12 SHA links match the commits' full hashes, scope↔path checks pass (fs/build(fs)→virt/arcbox-fs,vhost-user→virt/arcbox-vhost-user, docs →docs/), alphabetical placement within each section holds, and none touchrunner/orsdk/. Range completeness verified locally via rev-list: 99 first-parent commits sincev0.10.5— 96 changelogged on the path (97 distinct entries including the off-path IPv6 branch tip6958d54; 98 bullets, with1c544b7appearing in both BREAKING CHANGES and Code Refactoring), and the only unchangelogged commits remain76c464e8(riding in the companion PR #758, re-checked, still open) and the twomerge:-typed integrations (unchanged observation, not re-raised). - Regenerated the release and lockfile commits — the lockfile commit
17909d94isCargo.lock-only: 66 member version-bump pairs with zero dependency edges and no third-party drift (thee97ddc8dependency change's lock edges are base-side context, not part of this diff); the manifest (root.at 0.11.0,runner/sdkentries untouched) andCargo.tomlpins are identical to the previously approved state, with the manual-cadencearcbox-hv0.3.20 andarcbox-helper1.2.0 pins untouched and no0.10.5pin remaining. - Re-ran the lock↔manifest cross-check —
cargo metadata --no-deps --offlinesucceeds (the lockfile is in sync with every manifest): 69 members, exactlyarcbox-hv0.3.20,arcbox-helper1.2.0, andarcbox-runner-agent0.1.7 off the 0.11.0 version, zero mismatches; the diff still touches only the four release files, so the release config (draft+force-tag-creation) is untouched.
glm-5.3-flash ｜ 𝕏
|
🤖 Created releases: 🌻 |
🤖 I have created a release beep boop
0.11.0 (2026-11-03)
⚠ BREAKING CHANGES
Features
Bug Fixes
Code Refactoring
Tests
Documentation
Build System
Miscellaneous Chores
This PR was generated with Release Please. See documentation.