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.
🤖 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.