The snap publish step calls a command snapcraft still has

[PathGao]

What is broken

v2.7.4 shipped on 2026-08-14. The Snap Store still serves 2.6.11, revision 15, from 2026-06-03 — six versions and eleven days behind, and nobody has reported it, because from outside a stale snap looks identical to a current one: snapd checks daily and tells the user they are up to date.

The snap job in run 31775835301 got further than any run since June. It built:

Packed markpad_2.7.4_amd64.snap
gh release upload …                       ← the .snap is on the v2.7.4 release page
snapcraft push … --release stable
  The 'push' command was renamed to 'upload'.
  Recommended resolution: Use 'upload' instead.
  exit 64

snapcraft push has been in the workflow since February and last succeeded on 2026-06-03. snapcraft 8 turned the old name from a warning into a hard error; the job runs snap install snapcraft --classic, so it takes whatever the store serves and the command it calls stopped existing with no commit here.

It stayed hidden because the build failed first and the swallowed error reported success. #561 removed the swallowing, #577 and #579 fixed the build — which is what let v2.7.4 reach this line at all.

What changes

push → upload. Same arguments; only the command was renamed.

Two assertions in releaseWorkflow.test.ts matched on the literal snapcraft push, so they were updated. Worth being explicit about their limit, since it is the reason 972 passing tests said nothing: they pin the string this repository writes, not the command the tool has. Nothing runnable from npm test can check the second half — snapcraft is installed by the job, from the store, at release time. That is recorded in the test rather than left to be rediscovered.

And the decision this was waiting on: the snap stays

@alecdotdev posted the Metrics tab in #562. Reading it against the table in that issue:

Weekly active devices — by version, past year
     ┌ 100 ─────────────────────────────────
 173 │            2.6.11 ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓  ← today
 137 │      ╭────────────▓ 137
     └──────┴──────────────────────────────┘
          Jun 7                        Aug 22

~170, which is the "three figures or more, keep it" branch. The stronger half is the slope: the figure rose about 25% across the three months the channel was dead, with no version churn to explain it. That is not people who have not uninstalled — those are new installs, arriving now, landing on a June build. Waiting a week after 2.7.4 to re-read the number, as I suggested in that thread, is no longer necessary; the shape answers it.

So this also does the follow-up that branch attached to keeping the snap:

• removable-media. home reaches $HOME and nothing else, so a note on a USB stick or a second-drive mount was invisible to the app with no way for the user to grant it. It does not auto-connect — it takes one sudo snap connect markpad:removable-media — but without the plug declared there is nothing to connect.
• contact:, the one metadata warning the linter reports in the pack.

The other half of that branch, "stop recompiling", was #579.

What this does not do

Nothing moves the check earlier. #601 removed the pull-request snap check, so snapcraft.yaml and this job are still first executed against a tag that has already been published — this defect is exactly that arrangement's failure mode, and the fix does not change it. Raised in #562, not re-argued here.

It also does not recover 2.7.4. Once this merges, publish-packages.yml → Run workflow → v2.7.4 uploads the snap that is already attached to that release; the Chocolatey job checks the feed, finds markpad-app 2.7.4 published, and skips itself, which is what that check was added for.

Tests: 980 pass. Both edited assertions were checked by reverting the command and watching them fail.