What
A release checklist item, not a defect.
PR #129 originally carried 6e38d1c chore(release): 0.40.0. That commit was dropped before
merge, deliberately: npm-publish.yml fires on push to main, so merging the PR with the bump in
it would have published 0.40.0 to every @ipv9/tokentracker-cli user while several review
follow-ups were still open (#129's QA gate). Dropping it makes the merge repo-internal.
Current state — all four agree
|
|
package.json / package-lock.json |
0.39.44 |
TokenTrackerBar/project.yml (app + widget targets) |
0.39.44 |
TokenTrackerWin/TokenTrackerWin.csproj |
0.39.44 |
npm dist-tags.latest |
0.39.44 |
:17680 dashboard LaunchAgent pin |
0.39.44 |
validate:version-lockstep passes at this state. Nothing needs repinning today.
What to do when 0.40.0 should actually ship
Re-add the bump as its own commit in its own PR, so it stays the last thing before publish rather
than sitting mid-stack where a later review round can bury it. Then the normal flow: merge to main
(publish fires), dispatch release-dmg.yml with the version input to create the tag and the desktop
builds, then scripts/release.sh 0.40.0 to repin and verify the served bundle.
Note that tags are created only by dispatching release-dmg.yml — a merge alone does not tag,
and the version files disagreeing is what silently blocked desktop builds for 0.39.39–0.39.42.
Context
#129 (comment)
What
A release checklist item, not a defect.
PR #129 originally carried
6e38d1c chore(release): 0.40.0. That commit was dropped beforemerge, deliberately:
npm-publish.ymlfires on push tomain, so merging the PR with the bump init would have published 0.40.0 to every
@ipv9/tokentracker-cliuser while several reviewfollow-ups were still open (#129's QA gate). Dropping it makes the merge repo-internal.
Current state — all four agree
package.json/package-lock.json0.39.44TokenTrackerBar/project.yml(app + widget targets)0.39.44TokenTrackerWin/TokenTrackerWin.csproj0.39.44dist-tags.latest0.39.44:17680dashboard LaunchAgent pin0.39.44validate:version-locksteppasses at this state. Nothing needs repinning today.What to do when 0.40.0 should actually ship
Re-add the bump as its own commit in its own PR, so it stays the last thing before publish rather
than sitting mid-stack where a later review round can bury it. Then the normal flow: merge to main
(publish fires), dispatch
release-dmg.ymlwith the version input to create the tag and the desktopbuilds, then
scripts/release.sh 0.40.0to repin and verify the served bundle.Note that tags are created only by dispatching
release-dmg.yml— a merge alone does not tag,and the version files disagreeing is what silently blocked desktop builds for 0.39.39–0.39.42.
Context
#129 (comment)