chore(release): prepare 0.7.0 - #1219
Conversation
Bumps the eight published crates from 0.6.0 to 0.7.0, which is what the release workflow reads to tag and publish. It also clears the advisory Semver Checks job: cargo-semver-checks compares the manifest version against the last published one, and with both at 0.6.0 every intentional break since then reads as "requires new major version" (43 across wacore, wacore-binary and waproto). Pre-1.0, 0.6 to 0.7 is that major bump. whatsapp-rust-chat-store is held at 0.1.0 with publish = false. It would otherwise be published by --workspace as a brand new crate, and its schema and query surface are still moving. The GitHub release now prefers .github/release-notes/v<version>.md over --generate-notes, and 0.7.0's notes are added there. Generated notes for this release would be 488 unstructured bullets. docs/ is gitignored, so the notes live under .github/ next to the workflow that reads them.
|
Warning Review limit reached
Next review available in: 15 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Repository UI (base), Organization UI (inherited) Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughSummary by CodeRabbit
WalkthroughThe release updates workspace packages to version 0.7.0. The workflow validates the Cargo version, shares version and tag outputs, coordinates publishing jobs, skips existing releases, and selects release notes. Changesv0.7.0 release preparation
Estimated code review effort: 2 (Simple) | ~10 minutes Sequence Diagram(s)sequenceDiagram
participant ReleaseWorkflow
participant CargoManifest
participant GitHubReleases
participant DockerPublishing
ReleaseWorkflow->>CargoManifest: Extract package version
CargoManifest-->>ReleaseWorkflow: Return version
ReleaseWorkflow->>ReleaseWorkflow: Validate version and create tag
ReleaseWorkflow->>GitHubReleases: Check and create release
GitHubReleases-->>ReleaseWorkflow: Return release status
ReleaseWorkflow->>DockerPublishing: Pass validated version
Possibly related PRs
Suggested labels: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
| Filename | Overview |
|---|---|
| .github/workflows/release.yml | Adds an early version preflight, centralizes release identity outputs, supports versioned release-note files, and passes the validated version to Docker publishing. |
| Cargo.toml | Bumps the root package and all internal workspace dependency requirements to 0.7.0. |
| Cargo.lock | Synchronizes workspace package versions with the updated manifests. |
| storages/chat-store/Cargo.toml | Prevents publishing the evolving chat-store crate and updates its sqlite-storage dependency requirement. |
| README.md | Updates the documented whatsapp-rust dependency series to 0.7. |
Sequence Diagram
sequenceDiagram
participant Operator
participant Preflight
participant Validate
participant CratesIO
participant GitHub
participant Docker
Operator->>Preflight: Run release workflow
Preflight->>Preflight: Extract and validate Cargo.toml version
par Validation jobs
Preflight-->>Validate: Valid release identity
end
Validate->>CratesIO: Publish workspace crates
CratesIO-->>GitHub: Allow tag and release creation
GitHub->>GitHub: Use handwritten or generated notes
GitHub->>Docker: Invoke image workflow with validated version
Docker->>Docker: Publish versioned image
Reviews (5): Last reviewed commit: "docs(readme): point the quick start at 0..." | Re-trigger Greptile
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/release-notes/v0.7.0.md:
- Line 1: Add the top-level Markdown heading “WhatsApp Rust v0.7.0” before the
existing release summary in the release notes, leaving the summary text
unchanged.
In @.github/workflows/release.yml:
- Around line 94-99: Update the publish-docker invocation and the Docker
workflow’s checkout configuration so the Docker build is pinned to the release
tag/commit rather than resolving the default branch; pass the release tag
through the existing version input and use it in actions/checkout, preserving
the current behavior for newly created releases.
- Line 88: Harden the release workflow’s tag handling in the current release
step and the existing tag-creation step: pass the version output through the
step’s env as RELEASE_TAG, assign TAG only from "$RELEASE_TAG" rather than
interpolating it into shell source, and validate the tag before any release
commands use it.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI (base), Organization UI (inherited)
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 42979a42-a2fd-467d-965e-b8a97253e309
⛔ Files ignored due to path filters (1)
Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (15)
.github/release-notes/v0.7.0.md.github/workflows/release.ymlCargo.tomlexamples/voip-cli/Cargo.tomlhttp_clients/ureq-client/Cargo.tomlstorages/chat-store/Cargo.tomlstorages/sqlite-storage/Cargo.tomltransports/tokio-transport/Cargo.tomlwacore/Cargo.tomlwacore/appstate/Cargo.tomlwacore/binary/Cargo.tomlwacore/derive/Cargo.tomlwacore/libsignal/Cargo.tomlwacore/noise/Cargo.tomlwaproto/Cargo.toml
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
All reported issues were addressed across 16 files
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
📦 Binary size report
.text per crate
Top movers (cargo-bloat attribution)
Baseline: |
The 0.7.0 notes stay out of the repo; the workflow keeps preferring .github/release-notes/v<version>.md and falls back to --generate-notes, so adding one later needs no workflow change. Review follow-up: the version string becomes a git tag, a crates.io release and an image tag, and it came from a grep with no validation. It is now checked against semver at the point it is read, and reaches both steps through env instead of being expanded into the shell source.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/release.yml:
- Around line 74-77: Update the VERSION validation in the release workflow to
use Cargo’s SemVer parser or an equivalent strict pattern. Reject leading-zero
numeric components, leading-zero numeric prerelease identifiers, and empty or
repeated prerelease identifiers while preserving valid SemVer versions before
publishing.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI (base), Organization UI (inherited)
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: cf6f6b96-1d49-45c7-88bb-1ae0ef6d5a1f
📒 Files selected for processing (1)
.github/workflows/release.yml
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c764acbabd
ℹ️ 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".
There was a problem hiding this comment.
All reported issues were addressed across 2 files (changes from recent commits).
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
The version guard sat in github-release, which runs after publish. A version this workflow rejects but Cargo accepts would have published the crates first and then failed, leaving crates.io ahead of the repo with no tag, no release and no image, and crates.io publishes cannot be undone. It now runs in a preflight job that publish depends on, and github-release and publish-docker read the version from there instead of re-deriving it, so one job owns the string every later step keys on. The pattern also accepts build metadata. Being stricter than Cargo is the failure mode that matters here; being looser is not, since a version Cargo rejects never gets past publish.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/release.yml:
- Around line 40-46: Update the release version handling after validation to
derive and export a Docker-safe tag for publish-docker: reject build metadata
containing “+”, or normalize it into the Docker tag format and enforce Docker’s
128-character limit. Ensure the value passed to docker/metadata-action matches
the emitted image tag while preserving the existing version and release tag
outputs.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI (base), Organization UI (inherited)
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: f2d74dd4-d4cc-41a1-b6d5-2825d4339bd5
📒 Files selected for processing (1)
.github/workflows/release.yml
There was a problem hiding this comment.
All reported issues were addressed across 1 file (changes from recent commits).
Tip: Review your code locally with the cubic CLI to iterate faster.
Re-trigger cubic
`+` is not a legal Docker tag character, so docker/metadata-action rewrites it to `-`. A 0.7.0+build.5 release would publish under that version, tag v0.7.0+build.5, and then ship an image tagged 0.7.0-build.5, which is the tag a genuine 0.7.0-build.5 prerelease would claim. Metadata was allowed in the previous commit to keep the check from being stricter than Cargo, since a stricter check that ran after publish would strand the release. That check now runs in preflight, ahead of publish, so rejecting the form costs a failed job and nothing else.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 5dc20af8a0
ℹ️ 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".
`whatsapp-rust = "0.6"` resolves to `<0.7.0`, so anyone following the quick start after this release lands would keep getting 0.6.0.
There was a problem hiding this comment.
0 issues found across 1 file (changes from recent commits).
Confidence score: 5/5
- Automated review surfaced no issues in the provided summaries.
- No files require special attention.
Requires human review: Prepares an irreversible 0.7.0 crates.io release via version bumps and release-workflow changes; the diff is only metadata/tooling, so the release decision and operational release config still need human sign-off.
Re-trigger cubic
1 participant
What
Version bump for the 0.7.0 release, plus the two things that have to be decided before the release workflow runs.
The bump. The eight published crates go from 0.6.0 to 0.7.0.
release.ymldoes not bump anything: it reads the version already inCargo.tomlto tag, publish and name the Docker image, so this has to land first.It also clears the advisory Semver Checks job.
cargo-semver-checkscompares the manifest version against the last published one. With both at 0.6.0 it reportsChecking wacore v0.6.0 -> v0.6.0 (no change; assume minor)and every intentional break since then reads as "requires new major version": 30 forwacore, 3 forwacore-binary, 10 forwaproto(buffa renaming the generated types,#[non_exhaustive]on the event payloads, removed features). Pre-1.0, 0.6 to 0.7 is that major bump, so the job goes green on its own. It iscontinue-on-error, so nothing was blocked, but the summary was noise.whatsapp-rust-chat-storeis held back. It sits at 0.1.0 with nopublishkey, socargo release publish --workspacewould create it on crates.io as part of this release. Its schema and query surface are still moving, and publishing pins both.publish = falsefor now; the comment says how to undo it.Release notes. The workflow now prefers
.github/release-notes/v<version>.mdand falls back to--generate-noteswhen there is no file. For 0.7.0 the generated form would be 488 unstructured bullets. The notes for this release are added at.github/release-notes/v0.7.0.md, written in the shape of the 0.6.0 release: highlights, VoIP, performance with measured numbers, WA Web parity, breaking changes, contributors, and the full PR list in a<details>. They live under.github/becausedocs/is gitignored.Notes
whatsapp-rust-voip-climoves to 0.7.0 for consistency; it ispublish = falseand never leaves the repo.whatsapp-rust-plugin-metricsstays at 0.1.0, alreadypublish = false.Cargo.lockis the member-version update fromcargo update --workspace.After merge
gh workflow run release.yml --ref main, which validates, publishes to crates.io, tagsv0.7.0, creates the release from the notes file, and builds the image.