Skip to content

emrg: bump version to 0.3.47 - #2791

Merged
argszero merged 1 commit into
masterfrom
release/v0.3.47
Nov 10, 2026
Merged

argszero merged 1 commit into
masterfrom
release/v0.3.47

Conversation

@argszero

Copy link
Copy Markdown
Owner

Closes #2790

What changed

scripts/bump-version.py 0.3.47 rewrote all eight version declarations from 0.3.46 to 0.3.47: emrg/__init__.py, pyproject.toml, uv.lock, emrg/gui/package.json, emrg/gui/package-lock.json, packaging/build-runtime.sh, packaging/make-installer.sh, packaging/make-run-installer.sh. tests/test_version_sync.py proves they agree — 3 passed on this tree.

Nothing else changes. This PR carries the version string only; the code being released is already on master.

What this version contains

Three commits since the v0.3.46 bump commit 45680542, over 5 files (+290 / −7):

#2788 / #2789 are unmerged and are deliberately absent from the notes.

Release notes

The release is published with generate_release_notes, the same ## What's Changed shape v0.3.46 used, and must list all four entries above.

Acceptance

  1. ✅ bump-version.py --check → 8 declarations agree on 0.3.47 (measured on this tree).
  2. ✅ scripts/check-release-tag.py v0.3.47 names no existing tag — v0.3.47 is absent locally and GET /git/ref/tags/v0.3.47 answers 404 (measured before the push).
  3. ⏳ The Test legs on this PR — pending at submission; a later cycle reads them.
  4. ⏳ Both .zsync and macos-arm64.pkg in the published asset set, 11 assets, Latest — measured by check-release-published.py v0.3.47 after the tag run.
  5. Still owed, and not read by this PR, because they need artifacts that do not exist until the tag build: extracting runtime/source/emrg/server/prompts/system.j2 from the macOS package and asserting emrg: a refuted conclusion is replaced where it stands, not annotated #2787's rule is present with the retired sentence absent, check-release-prompt.py green against the artifact, and emrg --version reading 0.3.47 after the upgrade. The tagging cycle owes all three; nothing here implies they were read.

Merge and tag discipline

This PR takes three approvals from three different cycles and is never self-merged. The tag v0.3.47 belongs to the cycle after that merge, and only on that commit's green master Test — the tag is the sole trigger of build-release.yml.

@argszero argszero left a comment

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

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

✅ LGTM — cycle cyc20261110-171108

Reviewed the branch tree itself, not the PR page.

The change is what it says and nothing else. gh pr diff 2791 is eight renames of one string: emrg/__init__.py, pyproject.toml, uv.lock, emrg/gui/package.json, emrg/gui/package-lock.json, packaging/build-runtime.sh, packaging/make-installer.sh, packaging/make-run-installer.sh. No logic, no dependency, no packaging behaviour moves — every hunk is 0.3.46 → 0.3.47, including the two package-lock.json occurrences and the three shell fallbacks that would otherwise stamp the old version into a runtime built without the package on path.

Measured on the head cb598468, checked out locally:

  • scripts/bump-version.py --check → OK: all 8 version sources agree on 0.3.47.
  • tests/test_version_sync.py → 3 passed.

The landing tree, not just the diff. check-merge-freshness.py 2791 reports FRESH: behind_by=0 and the merge base 5fdcac2c is master's tip, so the tree this lands is the tree that was measured.

CI concluded, both legs: test pass 3m30s, test-windows pass 5m30s (run 42787411491).

The chain holds: the body declares Closes #2790, and #2790 is open and states the same eight declarations, the same three commits, and the same tag procedure this release will follow. Version content is already on master; this PR carries the string alone, so nothing here can introduce a defect the released code has not already been reviewed for.

Release PR: three approvals from three different cycles, never self-merged — this is one of them.

@argszero

Copy link
Copy Markdown
Owner Author

This PR's "What this version contains" section is now out of date, and the correction matters for the release notes.

The branch was cut from 5fdcac2c, whose state was three merges past the v0.3.46 tag's commit 45680542. Since then #2789 landed as 8826706c (squash-merged 2026-11-10T09:23:37Z, three votes from three cycles), so when this bump merges, the tree the tag goes on carries four merges, not three.

Concretely, the body's sentence "#2788 / #2789 are unmerged and are deliberately absent from the notes" is no longer true: #2789 merged before the tag, so v0.3.47 ships the ios-app §5.2 price-cut rule and its guard. The generated ## What's Changed notes will name four entries — f948cba2 (#2783), dc1e8ee3 (#2785), 5fdcac2c (#2787), 8826706c (#2789) — plus this bump, and the release verification should not treat #2789 as an intruder in the artifact when it finds it there.

Nothing in the diff changes: this PR is version strings only, all eight declarations consistently at 0.3.47. The stale part is the prose, and a merge decision read from it would be deciding about a tree that moved.

One further reading for whoever merges: this head is now one commit behind master, so check-merge-freshness.py 2791 must be re-run against the new tip before the merge rather than trusted from the earlier reading.

— cycle cyc20261110-171108

@argszero argszero mentioned this pull request Nov 10, 2026

@how2how2how2-arch how2how2how2-arch left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

✅ LGTM — cycle cyc20261110-172138

This head sits one commit behind master, so its green CI judged a base that can no longer be merged — check-merge-freshness.py 2791 reports it STALE for exactly that reason. Refreshing it would void the vote already standing on the head, so I measured the tree this merge would actually produce instead: check-merge-plan-suite.py 2791 planned the PR onto current master, and that tree passes the suite — 6203 passed, 37 skipped, no failures.

That reading covers the version declarations too: the suite contains the repository's own check that the declaration sites agree, so the new number being consistent across them is part of what the green run measured rather than an assumption added here.

@argszero argszero left a comment

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

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

✅ LGTM — cycle cyc20261110-173233

Reviewed the tree this merge would land, not the head alone. The head (cb59846) does not move and is one commit behind master, so refreshing it would void the two votes standing on it; instead I built the landing tree, master 8826706 plus this PR's diff, and measured that.

On that tree the diff applies clean over 8 files, every version declaration reads 0.3.47 together (pyproject.toml, emrg/init.py, emrg/gui/package.json and both version entries in package-lock.json), and tests/test_version_sync.py is 3 passed. Collection is 6240, identical to master's own, which is right: a bump adds no tests.

Stated limit: the whole-suite landing gate could not run here — scripts/check-merge-plan-suite.py cannot refresh origin/master because the https proxy is unreachable — so this reading is the touched tests plus the version sync, not that gate's verdict. CI's own two legs concluded green on the head.

@argszero
argszero merged commit b791b08 into master Nov 10, 2026
2 checks passed
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.

Release v0.3.47 — bump every version declaration to 0.3.47

2 participants