The helper this replaces was snapcraft release wekan $1 edge,beta,candidate, which is wrong three ways at once. It names only wekan, leaving wekan-ondra and wekan-gantt-gpl to be done by hand. It takes ONE revision number, and revisions are PER ARCHITECTURE - the store shows wekan at 3601 on amd64 and 3600 on arm64 for the same 10.76 - so one number can only ever be right for one of them. And it leaves out stable, so a build reached three channels of four and somebody had to remember the fourth.

releases/snap-release-all-channels.sh resolves the revision per (snap, architecture) from the store itself, so no revision number is ever typed, and releases it to all four channels in ONE call - a revision reaches all of them or none. A pair with no revision is reported and skipped rather than failing the run: the three snaps genuinely have different architecture sets today.

The mapping is the hazard, and it lives in one place now (models/lib/snapArchitectures.js) with both directions tested. ppc64le and ppc64el ARE the same hardware - the bundles use the kernel’s name, the store uses Debian’s - and it is the only rename. Nothing warns when the wrong one is used: an unrecognised architecture is simply one the store has never heard of, so it looks like it worked.

Pass the version to pin it. Without one the newest revision of each architecture is promoted, and edge is often ahead of stable, so a bare run publishes edge builds to stable users; --dry-run prints the plan first.

docs/Platforms/FOSS/Container/Snap/CPU-platforms.md listed five architectures and omitted armhf, which snapcraft.yaml has built all along. It said the release publishes candidate, beta and edge and that stable “is published manually later” - no longer true, and the reason a build reached three channels of four.

The matrix is now the six build-for: entries with the bundle name beside each, and a new section explains the three ways the two naming systems differ.

armhf and armv7 are not a rename, and getting it wrong ships a snap that crashes. node-patches builds armhf to the Debian baseline - hard-float, VFPv3-D16, assuming no NEON - so it runs on any ARMv7-A, and armv7 with NEON for boards that have it. The Snap Store has ONE 32-bit ARM architecture serving every such device, so it must carry the BASELINE build: the NEON one would be an illegal instruction on a board without NEON. So armv7 ships as a bundle only, and a test cross-checks that explanation against node-patches’ own workflow so it cannot drift from the binaries.

i386 cannot have a new snap at all, and it is categorically different from a missing Node.js build. node-patches patches SOURCE so a binary can be built; here the BASE SNAP does not exist, because Ubuntu 24.04 has no i386 port - no patch set produces a base Canonical does not publish. The last base with one was core18, end-of-life. The store still shows an i386 column for wekan-ondra because it keeps whatever was ever uploaded; that revision is 0.X-ci and nothing can replace it.

The page also records what each snap has in the store today and what is still to upload, including the two fossils channel promotion cannot fix - wekan-ondra’s armhf at 0.22 and its i386 at 0.X-ci, which have no newer revision to promote.