chore: sync ship-binary versions + NSIS PRODUCT_VERSION to 0.12.1#17
Merged
Conversation
The fork's GitHub release cadence drifted away from the in-tree version strings several PRs back (last bumped to "0.4.0" at #6; NSIS PRODUCT_VERSION stuck at "0.5.0" since then). v0.12.0 + v0.12.1 shipped without anyone noticing — `maxima.exe --version` reported "0.1.0", Windows "Add/Remove Programs" said "0.5.0", and the new `FInstall.txt`'s `maxima_lib_version` field showed "1.0.0". Sync them all to "0.12.1" (matching the upcoming release tag) for binary crates that ship in the installer: * maxima-cli 0.6.0 → 0.12.1 * maxima-bootstrap 0.6.0 → 0.12.1 * maxima-service 0.6.0 → 0.12.1 * maxima-tui 0.1.0 → 0.12.1 * maxima-ui 0.1.0 → 0.12.1 * installer/PRODUCT_VERSION 0.5.0 → 0.12.1 `maxima-lib` keeps version "1.0.0" — it's the library, not a shippable binary, and its version is referenced from `FInstall.txt`'s `maxima_lib_version` field. Bumping it isn't meaningful here. No functional changes; needed before re-tagging v0.12.1 (the earlier tag was yanked because it lacked this sync). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request synchronizes the version number to 0.12.1 across the installer and all workspace crates. The reviewer suggests adopting Cargo workspace inheritance to manage the project version and common dependencies from a single location, which would prevent the version drift seen in this PR.
| name = "maxima-bootstrap" | ||
| description = "Maxima handler for custom EA protocols" | ||
| version = "0.6.0" | ||
| version = "0.12.1" |
There was a problem hiding this comment.
To prevent future version drift (as noted in the PR description where some components were stuck at 0.1.0 or 0.6.0), consider using workspace inheritance. By defining the version once in the root Cargo.toml under [workspace.package] and using version.workspace = true in the member crates, you ensure all components stay in sync automatically. This pattern can also be applied to common dependencies (like tokio, serde, clap, etc.) to maintain consistency across the workspace.
Gemini suggested workspace inheritance to prevent the very drift this
PR is fixing. Solving the root cause beats fixing symptoms — apply it.
* Add `[workspace.package] version = "0.12.1"` to the root Cargo.toml.
Single source of truth, bumped at every release tag.
* Switch the 5 ship-binary crates (maxima-cli, maxima-bootstrap,
maxima-service, maxima-tui, maxima-ui) from `version = "0.12.1"`
to `version.workspace = true`. Next time only the root file needs
editing.
* maxima-lib and maxima-resources opt OUT (keep their literal
version):
- maxima-lib's version is referenced from `FInstall.txt`'s
`maxima_lib_version` field — we deliberately pin it at 1.0.0
even as ship-binary versions roll forward, so consumers of the
marker know which library API they're reading against.
- maxima-resources is a build-time helper; its version is internal
plumbing.
`cargo pkgid -p maxima-cli` now reports
`path+file:///…/maxima-cli#0.12.1`. Lockfile picked up the new
version cleanly.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
AA-EION
added a commit
that referenced
this pull request
May 21, 2026
Patch release covering: * fix: is_done() over-counting + decoder poisoning across retries (#19) → resolves the silent-hang-after-"Installation finished!" bug a user hit during a TF2 install with one CDN-failing file. The actual fix is already on master via #19. This PR just bumps the on-disk version strings before tagging v0.12.2. Thanks to the `[workspace.package] version` inheritance from #17, only the workspace root Cargo.toml + NSIS `PRODUCT_VERSION` need updating; the five ship-binary crates inherit automatically via `version.workspace = true`. Co-authored-by: AA-EION <contactus@eionstudios.com> Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
The fork's GitHub release cadence drifted away from the in-tree version strings several PRs back. NSIS
PRODUCT_VERSIONwas last bumped to0.5.0in #6; binary crate versions have been frozen at0.6.0/0.1.0since the fork started. v0.12.0 + (the now-yanked) v0.12.1 shipped without noticing —maxima.exe --versionreported "0.1.0", Windows "Add/Remove Programs" said "0.5.0", and the newFInstall.txt'smaxima_lib_versionfield showed "1.0.0".User caught it in code review while reviewing the v0.12.1 cut.
What
Sync ship-binary crates + the NSIS installer's
PRODUCT_VERSIONto0.12.1(matching the about-to-be-re-tagged release):installer/maxima-setup.nsiPRODUCT_VERSIONmaxima-cli/Cargo.tomlmaxima-bootstrap/Cargo.tomlmaxima-service/Cargo.tomlmaxima-tui/Cargo.tomlmaxima-ui/Cargo.tomlmaxima-lib/Cargo.tomlNo functional changes.
Cargo.lockis gitignored.Test plan
cargo check --target x86_64-pc-windows-gnu -p maxima-cli -p maxima-bootstrap -p maxima-service -p maxima-tui -p maxima-uipassesv0.12.1, verifyMaximaSetup.exeinstalls with the rightDisplayVersionin Windows registryContext
The yanked v0.12.1 was created before this sync; merging this and re-tagging gives us a clean v0.12.1 with consistent version strings throughout the install tree.
🤖 Generated with Claude Code