v10.62
Binaries in these bundles
Each bundle carries a Node.js, a FerretDB and the MongoDB Database Tools.
Which source has a given CPU varies from release to release - nodejs.org
builds some architectures, unofficial-builds others, and the
wekan/node fork the ones neither of them
does - and not every source publishes a checksum. This is what went into
this release, and which downloads were checked against a published
SHA256.
| Bundle | Binary | From | Version | Checked | SHA256 |
|---|---|---|---|---|---|
| arm64 | FerretDB | wekan/FerretDB | latest | no checksum published | — |
| arm64 | FerretDB | wekan/FerretDB | latest | no checksum published | — |
| arm64 | Node.js | GitHub runner (setup-node) | v22.23.1 | no checksum published | — |
| arm64 | Node.js | GitHub runner (setup-node) | v22.23.1 | no checksum published | — |
| ppc64le | FerretDB | wekan/FerretDB | v1.45.0 | verified | de4518c7774d3025… |
| ppc64le | FerretDB | wekan/FerretDB | v1.45.0 | verified | de4518c7774d3025… |
| ppc64le | Node.js | official | v24.19.0 | verified | c510c6ce12f07010… |
| ppc64le | Node.js | official | v24.19.0 | verified | c510c6ce12f07010… |
| riscv64 | FerretDB | wekan/FerretDB | v1.45.0 | verified | 7dc2952f554e8800… |
| riscv64 | FerretDB | wekan/FerretDB | v1.45.0 | verified | 7dc2952f554e8800… |
| riscv64 | Node.js | unofficial | v24.19.0 | verified | cd1f14af28121480… |
| riscv64 | Node.js | unofficial | v24.19.0 | verified | cd1f14af28121480… |
A row saying no checksum published is not a failed check - it is a
source that publishes nothing to check against. Those are the ones worth
fixing at the source.
v10.62 2026-08-04 WeKan ® release
In short: this release fixes the reason the release shipped no bundles,
which is what starved every downstream job (snap, Docker, AppImage) of the
wekan-<version>-amd64.zip they download - the 404s those jobs kept hitting
were never their own fault. The release job downloaded the bundles and then
checked the repo out, and actions/checkout's default clean deleted the
untracked zips before they could be attached; the checkout now keeps them. The
snap download also stops treating the brief post-upload 404 as fatal.
This release fixes the following release-build issue:
The release stops deleting its own bundles before attaching them. Thanks to xet7.
The release job downloads the per-arch bundles to the workspace root, then
checks the repo out (for the provenance script) before creating the GitHub
Release. actions/checkout defaults to clean: true, whose git clean -ffdx
deletes those untracked zips - so the "Create GitHub Release" step's
files: wekan-<version>-{amd64,arm64}.zip matched nothing. softprops does not
fail on unmatched files, so the release was created (job "success") with NO
bundles attached, and every downstream job that downloads one 404'd on
wekan-<version>-amd64.zip - the snap, Docker and AppImage failures were all
this. The checkout now sets clean: false, so the bundles survive and are
attached; the same fix went to the wekan-ondra and wekan-gantt-gpl forks, which
had the identical job. Separately, the snapcraft wekan part downloaded its
bundle with a single wget that treated a 404 as fatal, so it also broke on
the brief CDN lag right after an upload; it now retries like the other release
downloads. tests/releaseBundlesSurviveCheckout.test.cjs pins that a checkout
after the bundle download keeps clean: false.
Thanks to above GitHub users for their contributions and translators for their
translations.