chore(release): release 0.1.0 - #745
Conversation
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 07d1146ac7
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| [package] | ||
| name = "tracedecay" | ||
| version = "0.0.74" | ||
| version = "0.1.0" |
There was a problem hiding this comment.
Update the root lockfile to the release version
When this release commit is merged without the workflow's expected follow-up lockfile commit, Cargo.toml and version.txt become 0.1.0 while the root tracedecay entry in Cargo.lock remains 0.0.74. This makes bash tests/release_workflow_contract_test.sh fail with Cargo.lock root package and version.txt must stay aligned; because .github/workflows/ci.yml runs that contract on subsequent non-release PRs, the stale lockfile will block their Release Version Drift job.
Useful? React with 👍 / 👎.
ScriptedAlchemy
left a comment
There was a problem hiding this comment.
This release PR should not merge in its current form.
- The unresolved P1 on
Cargo.tomlis still valid: the release version must be reflected in the rootCargo.lockin the merge result, otherwise the repository's own release-version-drift contract fails on subsequent PRs. - More importantly, this release PR was generated before the current #707/#882 stabilization work. If 0.1.0 is meant to contain V2, do not manually keep rebasing this stale generated release body. Finish #882 -> #707, get the exact final #707 head green, merge it to master, then let Release Please regenerate/update the release PR from the actual master history. That avoids publishing release notes/version files that describe a different tree from the one being released.
- Re-run the release workflow contract on the regenerated head and verify the SDK/package version surfaces, Linux companion runtime packaging/install path, and root Cargo/version lockstep. #707 previously had release-path review findings in those areas, so release acceptance should test the installed artifact, not only archive construction.
Treat the bot's 'No Changeset found' warning as secondary here; this is a Release Please version PR. The correctness blocker is that the release metadata and lockfiles must be generated from the final releasable master tree.
ScriptedAlchemy
left a comment
There was a problem hiding this comment.
Deep current-tree release review.
The old Cargo.lock P1 is fixed in the present release diff: the root tracedecay package version now moves with Cargo.toml/version.txt. Do not carry that stale blocker forward.
The remaining problem is more fundamental: this Release Please PR was generated from the history that contains the accidental V2 merge and revert, before the current #707 integration tree is final. Its generated 0.1.0 changelog advertises consolidate TraceDecay V2 PR8-PR13 delivery and a large set of V2 fixes even though #707 is still open and #882 is still a required follow-up. Release Please is summarizing commit history, not proving that the final release tree contains those effects.
Treat #745 as stale release material. Do not manually patch the giant generated changelog around #707. Finish #882 -> integrate into #707 -> obtain green exact-head acceptance -> merge #707 to master -> regenerate/update the release PR from that master. Then verify that the regenerated release diff contains only version/manifest/changelog changes expected by the current release config, including the SDK/version authorities added in #707.
Before publishing 0.1.0, run the actual packaged install journey from the release assets, not just archive inspection: install.sh on Linux must retain the $ORIGIN ONNX companion (current #707 does now copy libonnxruntime.so*), tracedecay --version must work on a host without system ONNX Runtime, and SDK/package/version/lock authorities must agree.
The release PR should be the final projection of a known-good master tree, not a parallel integration branch.
Release review — holdKeeping this release blocked behind #707. The release artifact should represent the validated V2 product state, not just the existence of the V2 commits in history. Before cutting 0.1.0:
No issue with Release Please itself; the release boundary is premature until the V2 journey is proven. |
Release review — holdKeeping this release blocked behind #707. The release artifact should represent the validated V2 product state, not just the existence of the V2 commits in history. Before cutting 0.1.0:
No issue with Release Please itself; the release boundary is premature until the V2 journey is proven. |
ScriptedAlchemy
left a comment
There was a problem hiding this comment.
Release review — BLOCK / NO-GO
Reviewed 84639dbffb921bc3a2b0e3b6d99f8f078f3547fe: all five changed files and the returned workflow results. This release head's CI, Plugin Validation and hotpath-profile are green. That does not validate the current V2 integration tree.
The old lockfile objection is fixed: Cargo.toml, Cargo.lock, version.txt and the Release Please manifest all advance to 0.1.0. Do not carry that stale finding forward.
P0 — release provenance and product acceptance: the generated changelog is dated 2026-08-28 and advertises V2 PR8-PR13 delivery from historical commits, while #707 remains a deliberately unapproved draft and continues receiving correctness changes. Version-file consistency and a clean merge do not establish that the released tree contains the validated V2 behavior. Keep this blocked; do not use it as a parallel integration path.
When Zack authorizes a release target, regenerate the release proposal from that actual validated tree using its current release configuration. Do not manually transplant stale changelog claims or automatically merge/undraft #707 as a consequence of this review. Check all current Rust/CLI/SDK manifests and lockfiles, embedded/server version authorities and provenance as one release.
Required evidence before 0.1.0: final-tree semantic activation/successor/explicit rollback/exact retry and physical restart strict-query journey; runtime liveness and shutdown under contention; current supported-platform CI; bounded large-profile memory/convergence; and actual installed release artifacts. Linux installation must retain the packaged ONNX companion and launch without a system ONNX installation. Run macOS/Windows installation and supported journeys rather than relying on an archive build alone. Exercise the documented rebuild-required boundary for incompatible old stores without destroying unrelated durable user content.
No additional release changes are requested now beyond retaining the gate and accurate status. #707 stays DRAFT until explicitly authorized; this PR must not merge or publish 0.1.0 while that gate remains.
ScriptedAlchemy
left a comment
There was a problem hiding this comment.
System-level release re-review at 84639dbff — keep release gated
The release head is unchanged from the previously inspected five-file version/changelog diff. Refreshed workflow results still show CI, Plugin Validation and hotpath-profile succeeded. The root Cargo.lock/version mismatch is already fixed; it is not a remaining objection.
The release gate is the actual product tree, not this old release head's green checks. Its August 28 changelog advertises V2 delivery from historical commits, while #707 remains an explicitly unapproved draft and received another 108 commits during this review. At the final inspected integration SHA e9b203e25, I confirmed two outstanding production ownership defects: hook-span graph publication still bypasses the retained executor boundary, and cancellation of an LSP reaper waiter can leave its process slot reusable before confirmed settlement. The detailed findings and other child-PR gates are posted on #707 and the corresponding PRs. None is validated by this release branch's older checks.
Do not use #745 as a parallel integration or automatic publication path. Once Zack explicitly authorizes a validated release tree, regenerate the release proposal using that tree's current version/configuration authorities. Verify current Rust/CLI/SDK/server/embedded versions and lockfiles together, rather than transplanting historical changelog claims into a newer artifact.
Acceptance must exercise installed artifacts as well as compilation: supported native-platform launch and advertised behavior; Linux installation retaining the packaged ONNX companion without relying on a system installation; the uncached semantic activation/successor/explicit rollback/exact retry/cold restart/strict-query journey; and bounded runtime settlement, retention and backup/restore. Failed operations must preserve pre-existing durable content. Test the documented incompatible-store/rebuild boundary without treating every store as disposable derived material.
Optional cache/performance work need not become an additional release dependency: leave an unvalidated optimization out rather than requiring every open child PR to merge. What is included must have final-tree evidence. No additional version-file edit is requested while the product gate remains closed, and this review does not authorize undrafting/merging #707 or publishing 0.1.0. No installed-artifact tests were executed here.
ScriptedAlchemy
left a comment
There was a problem hiding this comment.
Release review at current head 84639dbffb9:
The earlier root Cargo.lock mismatch is fixed on this head; the diff now updates .release-please-manifest.json, Cargo.toml, Cargo.lock, version.txt, and the changelog together.
The remaining blocker is release truth. This generated 0.1.0 changelog still advertises consolidate TraceDecay V2 PR8-PR13 delivery and a large body of V2 follow-on fixes/perf work while #707 is intentionally still DRAFT and master is still the pre-V2 0.0.74 tree. The release PR was generated from history that included the accidentally merged/reverted V2 work, so its changelog is not a truthful description of the tree we are presently authorizing for release.
Do not hand-edit the generated changelog around this. Hold this PR until #707 has its actual release decision and final accepted head. If V2 ships, merge the accepted #707 tree first and let Release Please regenerate from resulting master history. If V2 does not ship in 0.1.0, regenerate release metadata from the actual non-V2 master history so reverted commits are not marketed as shipped features.
Acceptance before this release PR can merge: generated notes correspond to commits present in the release tree; version/lock/manifest surfaces remain in lockstep; release workflow/package/install smoke runs against the generated release head. The changesets-bot warning is secondary to this provenance mismatch.
🤖 I have created a release beep boop
0.1.0 (2026-08-28)
Features
Bug Fixes
Performance Improvements
Reverts
This PR was generated with Release Please. See documentation.