Skip to content

bump version - #55

Closed
The64thRealm wants to merge 2 commits into
mainfrom
bump-ver
Closed

bump version#55
The64thRealm wants to merge 2 commits into
mainfrom
bump-ver

Conversation

@The64thRealm

Copy link
Copy Markdown
Contributor

new release bumps pinned play version, adds confirmation before publishing, adds a command to list achievements

@claude

claude Bot commented Aug 14, 2026

Copy link
Copy Markdown

Claude finished @The64thRealm's task in 2m 55s —— View job


Code Review

  • Gather context (PR diff, repo layout)
  • Run code review
  • Post findings

Scope: This PR's diff against origin/main is a single hunk — Cargo.toml version 0.1.920.1.93. The features named in the PR body (pinned play version, publish confirmation, achievements list) all landed in the base merge commit beade68, so they aren't part of this diff and weren't reviewed here.


Findings (1)

Cargo.toml:3Cargo.lock not bumped alongside the manifest

Cargo.lock:3079 still pins wavedash = "0.1.92", so the committed lockfile is now inconsistent with the manifest. Concretely:

  • Any --locked / --offline build of the 0.1.93 tag fails with "the lock file needs to be updated but --locked was passed" — this includes cargo install --locked, the idiomatic install path for a published CLI.
  • .github/workflows/ci.yml passes no --locked flag, so CI will pass while silently rewriting the lockfile. The failure is invisible until someone builds reproducibly from the tag.
  • At beade68 the two were in sync (both 0.1.92), so this is a regression introduced by this PR rather than a pre-existing drift.

Fix is cargo update -p wavedash --precise 0.1.93 (or just cargo check) and commit the resulting Cargo.lock.

Fix this → · inline comment


Checked and clean

  • 0.1.93 is a correct monotonic patch bump from 0.1.92.
  • No other file hardcodes the version — src/config.rs:114 and src/updater.rs:3 read CARGO_PKG_VERSION at compile time, so the self-updater and User-Agent pick up the new value automatically.
  • .github/workflows/auto-tag.yml's version extraction (^version =) still matches the changed line, and the tag name format is unchanged.
  • dist-workspace.toml and release.yml need no version edits.
  • The pinned src/dev/sdk-js-version (1.3.43) is untouched by this diff; its consistency with play is enforced at tag time by the auto-tag pre-check.
    · Branch: bump-ver

devin-ai-integration[bot]

This comment was marked as resolved.

Comment thread Cargo.toml
[package]
name = "wavedash"
version = "0.1.92"
version = "0.1.93"

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cargo.lock still records the old version — the wavedash entry at Cargo.lock:3079 is version = "0.1.92", so with this bump the committed lockfile no longer matches the manifest.

Nothing in CI passes --locked, so cargo clippy / cargo test will silently rewrite the lock and still pass, but anyone building the 0.1.93 tag with a frozen lockfile hits it: cargo build --locked (or --offline, or cargo install --locked) fails with error: the lock file .../Cargo.lock needs to be updated but --locked was passed to prevent this. It also means the released tag's lockfile does not record the version actually shipped. The previous release (beade68) kept the two in sync, so this is a regression in that convention.

Fix by regenerating the lock alongside the manifest bump (cargo update -p wavedash --precise 0.1.93, or just cargo check) and committing Cargo.lock.

@claude

claude Bot commented Aug 14, 2026

Copy link
Copy Markdown

Claude finished @The64thRealm's task in 1m 27s —— View job


Code Review

  • Gather context (PR diff, repo layout)
  • Re-review after 7dd7ed9 update cargo lock
  • Post findings

Scope: The full diff against origin/main is two lines — 0.1.920.1.93 in Cargo.toml:3 and the matching wavedash entry in Cargo.lock:3079. The features named in the PR body (pinned play version, publish confirmation, achievements list) all landed in the base merge commit beade68, so they aren't part of this diff and weren't reviewed here.


Findings (0)

No issues found.

The Cargo.lock drift flagged on the previous revision is resolved — 7dd7ed9 bumps the lockfile's wavedash entry to 0.1.93, so --locked / --frozen builds of the release tag (cargo install --locked, cargo-dist's release job) will now resolve without needing to rewrite the lock.


Checked and clean

  • Manifest/lock in sync. Cargo.toml:3 and Cargo.lock:3079 both read 0.1.93. wavedash appears exactly once in the lockfile, and since this is a single-package crate (no workspace members, dist-workspace.toml:2 is members = ["cargo:."]), bumping the root package's version is the only lockfile change cargo would produce — no dependency re-resolution is implied, so the one-line lock diff is complete rather than partial.
  • Correct bump. 0.1.93 is a monotonic patch increment from 0.1.92.
  • No hardcoded versions elsewhere. A repo-wide grep for 0.1.9[23] outside Cargo.lock matches only Cargo.toml:3. src/config.rs and src/updater.rs read CARGO_PKG_VERSION at compile time, so the self-updater and User-Agent pick up the new value automatically.
  • Tagging still works. .github/workflows/auto-tag.yml:25 extracts the version with grep '^version =' Cargo.toml | head -n 1, which still matches the changed line, and the tag format at line 62 is unchanged. The workflow is also triggered by paths: Cargo.toml, so this bump will fire it on merge.
  • No release-config edits needed. dist-workspace.toml pins cargo-dist-version independently of the crate version, and release.yml derives the version from the tag.
  • src/dev/sdk-js-version untouched by this diff; its consistency with what play ships is enforced at tag time by the pre-check at .github/workflows/auto-tag.yml:39-54.
    · Branch: bump-ver

@The64thRealm
The64thRealm deleted the bump-ver branch August 14, 2026 19:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant