WeKan took its Node.js only from the wekan/node fork, for every platform. That fork is retired in favour of wekan/node-patches, which carries patches rather than a whole Node.js source tree - so the question “where does this platform’s Node.js come from” had to be answered again, and the answer is now three sources tried in order: nodejs.org, then unofficial-builds.nodejs.org, then wekan/node-patches.

The order is a preference, not a last resort. Where nodejs.org publishes a build, that is the one WeKan ships: it is the build the rest of the world runs and its checksums are the ones everyone else verifies against. unofficial-builds covers the CPUs nodejs.org does not release - riscv64 and loong64 - and node-patches covers what neither publishes at all: 32-bit x86, 32-bit ARM and 32-bit Windows.

releases/resolve-node-source.sh is the one place that order and the platform-name mapping live. The bundle jobs (through releases/embed-verified-node.sh), the extra-architecture preflight (releases/check-arch-binaries.sh) and the Dockerfile all ask it, so the image and the .zip of one CPU cannot be built on Node.js from different places - which is exactly what happened when each of them carried its own copy of the walk. The snap copies its node out of the bundle, so it follows with no change of its own, and Sandstorm is amd64-only and untouched.

It answers with the exact file, what shape that file is - nodejs.org and unofficial-builds publish a tarball or a .zip, node-patches a bare binary - and the SHA256 that source published for it. Because it only returns a build it found a published checksum for, the “shipped unverified” path that a missing .sha256sum used to open is gone.

There is nothing a release run can do about a CPU nobody publishes a runtime for, so it no longer tries: the resolver answers “not found”, the preflight in each bundle job turns that into a skip, and every step after it is gated on that. A red job every release for such a CPU is noise, and when it was an error it took the whole extra-architecture matrix with it - and, through that, the Docker image and the jobs that need it.

Nothing has to be edited when that changes. The next run resolves again, and the platform builds the moment a Node.js for it is published at any of the three sources. That is what the four missing rows in the table above are: i386, armhf, armv7 and win32 are waiting for wekan/node-patches to publish its first release, and they come back by themselves when it does.

A lookup that could not be MADE is kept apart from an answer of “nobody publishes it”: an unreachable nodejs.org is an error, not a reason to skip every platform and call an empty release normal.

Every bundle job recorded its Node.js provenance row with the literal source wekan/node, whatever had actually served, so the provenance table at the top of the release notes could not answer the one question it exists for. The rows now carry what the embed step reported - nodejs.org, unofficial-builds.nodejs.org or wekan/node-patches - together with the exact URL and the verified SHA256.

The same table is now part of the CHANGELOG too, at the top of each release section under the summary, so which binaries a release carries can be read without a build log that expires. CLAUDE.md describes its shape.

A 32-bit Windows native addon must link against an ia32 node.lib, and nodejs.org stopped publishing one in Node 23, so node-gyp is pointed at a nodedir built by hand: headers from nodejs.org plus a node-win32.lib. That library came from the retired fork; it now comes from wekan/node-patches, which is also where the node-win32.exe in the bundle comes from. The addons and the runtime they run on are then from the same build.

tests/releaseNodeSources.test.cjs is new and pins what the change above is worth: that the three sources are tried in that order, that version is the outer loop and source the inner one - so a current patched build beats an ancient official one rather than the other way round - that every consumer asks the one resolver instead of carrying its own walk, that a platform with no Node.js is a skip rather than a failure, and that no file downloads from the retired fork any more.

releaseNodeVerified and releaseArchSkipAndBaseAttach pinned the fork-only rule, which was the correct rule until this release. They are updated to the new one and say in the test why, so the next reader can see it was a decision. Each keeps the assertion that made it valuable: a named version, a verified download, and no path that ships an unverified Node.js.

releaseSnapArches read release: out of ordinary English in a run: block and took the following word for a snap channel; it now keeps only the matches that name one. node-patches, checked out beside WeKan, is added to .meteorignore for the same reason the other sibling repositories are there.