Bump the product version to 0.1.4 - #601
Merged
Merged
Conversation
All five sites the version-sync lint pins, so a partial bump cannot pass: VersionFallback, the .dproj FileVersion and ProductVersion strings, the structured Release field Delphi writes into VS_FIXEDFILEINFO, and the installer default. The structured field is the one that matters most and is easiest to miss. Delphi puts it in the binary's fixed version block, which is what Windows Explorer, installer upgrade comparisons and inventory tooling read -- the FileVersion string can say one thing while the fixed block says another. Verified by reverting just that field, which fails lint-version with exactly that explanation. Changelog entry for #600 in both mirrors (docs/changelog.md and the README section), under a new 2026-09 heading, with the reference-link definition the entry cites. Note for whoever cuts the release: lint-version reports "no tags reachable" here, so its behind-the-newest-tag check -- the drift that shipped 0.1.0-dev through three releases -- is currently inert. It needs a clone with tags in history (fetch-depth: 0 in CI) to do the job it exists for. The cross-site checks run either way. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LGQKz579j1ZnDRwmr6h1V6
![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: 215af0f998
ℹ️ 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".
|
|
||
| #ifndef MyAppVersion | ||
| #define MyAppVersion "0.1.3" | ||
| #define MyAppVersion "0.1.4" |
There was a problem hiding this comment.
After changing the Inno Setup default to 0.1.4, installer/README.md:51 still states that MyAppVersion defaults to 0.1.3. Anyone consulting the installer documentation now sees a value that disagrees with the behavior of the documented iscc commands, so update that table entry as part of the version bump.
Useful? React with 👍 / 👎.
installer/README.md's options table still said MyAppVersion defaults to 0.1.3 after the .iss default moved to 0.1.4, so anyone following that table would pass a stale version to iscc. Swept the rest of the tree for the same drift: this is the only stale reference. The other 0.1.3 mentions are historical prose in check-version-sync.py's docstring describing the incident that prompted the lint, which should stay, and multicast addresses in vendored Indy. Also added the site to check-version-sync.py. The lint's stated premise is that a partial bump cannot pass, and this doc drifted on the first bump after the lint was written -- which is evidence its coverage was one site short rather than evidence the bump was careless. Negative-tested: reverting just that table cell now fails with "documented MyAppVersion default is 0.1.3, but VersionFallback is 0.1.4". Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LGQKz579j1ZnDRwmr6h1V6
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
2 participants
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.
Version bump ahead of the v0.1.4 release, plus the changelog entry for #600.
The five version sites
All of the ones
scripts/check-version-sync.pypins, so a partial bump cannot pass:PasClaw.Config.pas—VersionFallback.dproj—FileVersion.dproj—ProductVersion.dproj— structuredReleaseinstaller/pasclaw.iss—MyAppVersionThe structured field is the easy one to miss and the one that matters most: Delphi writes it into the binary's
VS_FIXEDFILEINFOblock, which is what Explorer, installer upgrade comparisons and inventory tooling read — theFileVersionstring can say one thing while the fixed block says another. Verified by reverting just that field, which failslint-versionwith exactly that explanation.Changelog
Entry for #600 in both mirrors (
docs/changelog.mdand the README section), under a new## 2026-09heading, with the[#600]reference-link definition the entry cites.Between
v0.1.3andmainthere is exactly one feature PR, so 0.1.4 is a single-feature release: the static embedding tier,memory_write, and the embedder-identity fix.Verification
make testgreen —SUITE-EXIT=0, 38 suites, 0 make errors,version sync: OK.Two things for whoever cuts the release
Neither is caused by this PR and neither is fixed here, but both bear on v0.1.4 specifically.
1. Build the Delphi exes from a checkout that includes this bump.
release-artifacts.ymlis hybrid: the Linux tarball is built in CI withmake VERSION=<tag>, so it reports 0.1.4 from the tag regardless — but the Windows installers wrapPasClaw-x64.exe/PasClaw-x86.exethat are built locally, and the Delphi build has noVERSIONoverride, so it shipsVersionFallbackverbatim. Build those from currentmainand the installer filename would say 0.1.4 whilepasclaw version,/v1/version, the gateway'sServer:header andpasclaw updateall say 0.1.3. Nothing in the workflow cross-checks the attached exe against the tag, so that mismatch would ship silently — which is the exact failure mode that put 0.1.0-dev in three releases.2. The lint's tag check is currently inert. No workflow runs
make testorlint-versionat all, and all threeactions/checkout@v4steps omitfetch-depth, so CI clones shallow with no tags. Even if a workflow did run the lint, its behind-the-newest-tag comparison — the whole reason it exists — would skip, exactly as it does in this sandbox (no tags reachable, tag comparison skipped). The cross-site checks still run either way. Worth a follow-up: run the lint in CI withfetch-depth: 0.🤖 Generated with Claude Code
https://claude.ai/code/session_01LGQKz579j1ZnDRwmr6h1V6
Generated by Claude Code