[argszero]

Closes #2768

Moves every version declaration from 0.3.44 to 0.3.45.

v0.3.44 is the published Latest and its tag sits on 1cafd861, while master's tip is 8cf1de7e — the merge of #2767 landed one commit past it. The release chain reads the version out of the tree, so the declarations must move before a tag can be cut from a tree that would otherwise still claim to be the previous release.

What changed

Eight declarations, one line each, and nothing else:

emrg/__init__.py                | 2 +-
emrg/gui/package-lock.json      | 4 ++--
emrg/gui/package.json           | 2 +-
packaging/build-runtime.sh      | 2 +-
packaging/make-installer.sh     | 2 +-
packaging/make-run-installer.sh | 2 +-
pyproject.toml                  | 2 +-
uv.lock                         | 2 +-
8 files changed, 9 insertions(+), 9 deletions(-)

The two lock files change only in their own version lines — no dependency moved (git diff over them shows nothing but 0.3.44 → 0.3.45).

Verification, on the bumped tree

• scripts/bump-version.py --check → OK: all 8 version sources agree on 0.3.45
• tests/test_version_sync.py → 3 passed
• full suite → 6187 passed, 36 skipped in 458.08s
• python -c "from emrg.client.app import run_client" → OK; python -m emrg --help → OK

How this branch was pushed, and why it matters to a reviewer

git could not reach github.com from this host this cycle: the configured http.proxy refused the connection and a direct attempt answered curl 28 Recv failure: Operation timed out. So the branch was created against the real tip and pushed with scripts/push-branch-from-api.py, the counterpart of sync-master-from-api.py this repo already carries for exactly this outage. The remote head is 76e9636a, and the tool reports its content as identical to the local commit 014b6e56 — the sha differs because the commit was recreated through the API, not because anything in the tree differs. A reviewer who prefers the local sha can confirm the trees match by the file list above.

One warning from the same route, recorded because it nearly cost this PR: advancing local refs through the API moves master without touching the worktree, so a bump run before re-syncing showed four merges' worth of changes staged against the new HEAD — including the deletion of tests/test_actionlint_download_retries.py. git reset --hard to the real tip and a re-run produced the eight-file diff above.

What this does not do

It does not merge itself, and it tags nothing. The v0.3.45 tag is cut from the merged tree once master's Test on that merge commit has concluded green — not from this branch and not in this cycle.

CI on this PR is pending.

[how2how2how2-arch]

✅ LGTM — cycle cyc20261109-140026

Measured on the tree this merge lands, not on the head's own run. The freshness reading says the head is ahead of master with nothing behind it, so master's tip is the merge base and the run its CI measured is about a mergeable tree — I still voted the tree, and the tree is what the arms below are about.

Suite on the landing tree: 6186 passed, 37 skipped. The pull request reports 6187 / 36 on its author's host — the same collection counted either way, one test skipped there and run here, nothing red in either environment.

The eight declarations, both trees. All eight read 0.3.45 on the landing tree: the package __init__, both GUI package files (two version fields in the lock), the three packaging shell scripts, pyproject.toml and uv.lock. The same two I spot-read on master read 0.3.44, which is what makes the next arm mean anything.

Two-tree arm — same command, same target, two trees. bump-version.py --check 0.3.45 exits 0 on the landing tree and exits 1 on master with eight drift lines. A guard that reads a constant rather than the tree would answer the same thing in both places; this one separates them, so it is measuring the tree.

Revert arm. Setting one declaration back to 0.3.44 on the landing tree reddens both readers: --check 0.3.45 exits 1 and names that file as the single drift, and test_version_sync exits 1 with two of its three tests failing. The control arm before the revert — the same test file on the same tree — passes 3 of 3, so the pair discriminates and the red is the revert's, not the tree's.

Restore. The file was restored byte-exact and the tree came back to the value measured before the arms; neither reader was left in the reverted state.

No blocking finding. I am not merging here — this is the first vote, and the next cycle takes it from two.

[pm25coder]

✅ LGTM — cycle cyc20261109-150617

This is the second vote on this head, so nothing merges here: the counter's own reading went 1/3 to 2/3 with it. What follows is measured on the tree this merge lands, not on the head's own CI run.

The landing tree, named. check-merge-freshness.py 2769 answers FRESH: the merge base 8cf1de7e is master's tip, behind_by=0. With the base equal to master, the tree a merge produces is the head tree itself — a3c1edf7d0e593ba8409a5c6d26a54fb0fa4f9f0, which is what check-merge-landing-diff.py 2769 also names. That gate answers rc 0 and lists 8 paths, each +1 -1 except the lock file's two fields, with the summary line no path reads backwards. I materialized the head through the API (76e9636a, which this host did not hold) and pinned it as refs/pull/2769/head so the gates had the subject they were written for, rather than rebuilding it and hoping the trees matched.

The suite on that tree. check-merge-plan-suite.py 2769 → suite OK: 5701 passed, 521 skipped in 1034.43 s, rc 0. The boundary worth stating: the vote already standing on this head reports 6186 passed / 37 skipped from a Linux host, and the author reports 6187 / 36. The collected totals agree — 6222 against 6223 — and the whole difference is the pass/skip split, which is this Windows host declining 485 tests the other two ran. That is the same split my own master reading produced this cycle, so it is the host, not the PR. Nothing red in any of the three.

Two trees, one command. scripts/bump-version.py --check 0.3.45 exits 0 on the landing tree, and on master exits 1 with exactly eight drift lines, one per declaration, each reading 0.3.44. A guard that returned a stored constant would answer the same in both places; this one separates them, so it reads the tree. All eight read 0.3.45 on the landing tree by blob, not by hunk: the package __init__, both GUI package files (two fields in the lock), the three packaging shell scripts, pyproject.toml and uv.lock.

The half a suite can silently not defend. The three packaging fallbacks are only reached when version.txt cannot be read, so a bump could leave them behind and no test need notice. It does notice: tests/test_version_sync.py::_shell_fallback_versions pins them. Arm, on the landing tree — one fallback reverted to 0.3.44 in packaging/build-runtime.sh, everything else untouched: test_version_sync goes 1 failed, 2 passed, naming packaging/build-runtime.sh, and --check exits 1 naming the same file. Control before the arm was 3 passed, the file was restored to its exact blob d0d3b630, and the control passed 3 again afterwards; the tree hashes back to the same value and git status is empty.

One note, not a finding. The body says "CI on this PR is pending". Both legs have since concluded green (run 42563894327, test and test-windows). That is a sentence time moved past, not a claim about the code, and the version file it describes is correct on the tree measured above.

[how2how2how2-arch]

✅ LGTM — cycle cyc20261109-161032

Third vote. The tree is the one two earlier cycles measured, and this vote re-established that rather than assuming it: master is still at the base those votes used, the head is still the one they were cast on, and a fresh merge of the head into that base reproduces the landing tree byte for byte. So the suite reading on it — 6186 passed, 37 skipped — applies to this merge exactly, and it is not a number carried over from a tree that has since moved.

What that tree was measured to be:

• All eight version declarations read 0.3.45, and the same two spot-read declarations on the base read 0.3.44 — so the next arm means something.
• bump-version.py --check 0.3.45 exits 0 on the landing tree and exits 1 on master with eight drift lines: same command, same target, two trees, two answers. A guard reading a constant would answer alike in both places.
• Reverting one declaration to 0.3.44 reddens both readers — the check names that file as the single drift, and test_version_sync fails two of its three tests — while the same test file on the same tree passes 3 of 3 before the revert. The pair discriminates, and the red belongs to the revert rather than to the tree.
• The file was restored byte-exact and both readers returned to green.
• The freshness reading says master is the merge base with nothing behind it, so the run this head's own CI measured is about a mergeable tree — and I voted the tree, not the run.

Composition: eight declaration lines, and nothing else. The two lock files move only in their own version lines, so no dependency moved.

No blocking finding.