The release lags master: cut 0.3.40 so an upgrade carries the self-media publish round #2730

Activity

1. argszero commented on Nov 5, 2026

   

   argszero

   on Nov 5, 2026

   OwnerAuthor

   More actions

   Handled by #2731
2. how2how2how2-arch commented on Nov 5, 2026

   

   how2how2how2-arch

   on Nov 5, 2026

   Collaborator

   More actions

   The bump landed on master as 6e70bc7d ("emrg: bump version to 0.3.40", PR #2731, merged 2026-11-05T19:56:31Z). All eight version declarations on master now read 0.3.40 — bump-version.py --check reports them agreeing, and the version-sync guard passes on the merged tree.

   What this closes and what it does not. This issue names the lag between master and the declared version, and that lag is gone: an installation that upgrades from here on can see a newer version, and master no longer carries merged work under a version number that predates it. The release is the next stage and it has not started: no tag has been pushed, so nothing has been published, and the acceptance items that require check-release-tag.py on the tag commit and a published, non-draft, non-prerelease release are still ahead.

   What remains, in order:

   1. The Test run on 6e70bc7d concludes green — the gate is that exact merge commit, not the branch that carried it.
   2. An annotated v0.3.40 tag is pushed, which is the only trigger of the release build.
   3. The release build is read to its end, per platform leg.
   4. scripts/check-release-published.py v0.3.40 reports the release published as Latest, not a draft and not a prerelease, with the full asset set.

   Until step 4 passes, the version number is bumped but not shipped, and this issue should be read as tracking that second half rather than the bump.
3. argszero commented on Nov 5, 2026

   

   argszero

   on Nov 5, 2026

   OwnerAuthor

   More actions

   The tag is cut. v0.3.40 is now an annotated tag on 6e70bc7d, pushed at 2026-11-05T22:5xZ, and
   that is a claim with its own two readings rather than a statement about the merge:

   • git ls-remote --tags origin 'v0.3.40*' answers two lines — refs/tags/v0.3.40 = 64ebd080, and
     refs/tags/v0.3.40^{} = 6e70bc7d. The ^{} line is the peel, and it is what the release build
     reads: build-release.yml refuses an object.type that is not tag, so a lightweight tag here would
     have been a guaranteed red build and a version that shipped dead.
   • The API agrees from the other side: git/ref/tags/v0.3.40 answers type=tag, and the tag object
     itself carries tagname=v0.3.40, target=commit 6e70bc7d.

   Before any of that, the two gates this issue's own acceptance names:

   • The tree's Test concluded green on the commit being tagged — run 42098668735 on 6e70bc7d read
     completed / success with both legs finished (test, test-windows). The tag gates on that commit,
     not on the branch that carried it.
   • The tag name resolves to the version the tagged tree declares — bump-version.py --check reads all
     eight declarations agreeing on 0.3.40, and check-release-tag.py v0.3.40 answers OK: tag v0.3.40 names the version this tree declares.

   What is left, and this issue stays open for it. Pushing the tag fired build-release.yml as run
   42125656608, which read queued at the reading this cycle took — a park, never a pass. Nothing
   here says 0.3.40 is published: no release object exists yet, no asset exists yet, and the four platform
   legs (macOS signing and notarization among them) have not run. The release is closed by
   check-release-published.py v0.3.40 answering non-draft, non-prerelease, Latest and the full asset set —
   and only then does this issue close. The installed copy is a further step after that: install/version.txt
   still reading 0.3.39 is the host's upgrade, not a defect here.
4. argszero commented on Nov 5, 2026

   

   argszero

   on Nov 5, 2026

   OwnerAuthor

   More actions

   Published. check-release-published.py v0.3.40 answers OK: v0.3.40 built green and is published -- not a draft, not a prerelease, 11 asset(s), and every acceptance item this issue named is now a
   reading rather than a hope:

   • The build concluded green on the tagged commit — run 42125656608, completed / success, all
     four platform legs finished success, the macOS leg (signing and notarization) among them. It ran
     18 minutes, which is why the earlier reading said queued: a build that has not concluded is a park,
     and nothing here was re-run to hurry it.
   • The release object exists and is the public one — draft=false, prerelease=false, 11 assets:
     EMRG-0.3.40-macos-arm64.pkg, EMRG-0.3.40-windows-x64.exe, EMRG-0.3.40-windows-x64.zip, the three
     Linux bundles with their .tar.gz/.run, plus two AppImage and two .zsync.
   • GitHub's Latest points at this tag — releases/latest answers v0.3.40, so an installation
     checking for updates sees 0.3.40 as the version to move to, which was the whole point of the bump.

   What still is not true, and is nobody's defect here: the copy installed on this machine reads
   0.3.39 in install/version.txt. A merge publishes nothing, a tag publishes nothing, and a green build
   publishes nothing to a host — only the host's own upgrade moves the installed copy, and that is the
   host's action to take.
5. argszero

   closed this as completedon Nov 5, 2026