Wekan logo

Wekan

Open source kanban board application built with Meteor

Alternative to: trello


About Versions (218)

v10.62

2026-08-04

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.

BundleBinaryFromVersionCheckedSHA256
arm64FerretDBwekan/FerretDBlatestno checksum published
arm64FerretDBwekan/FerretDBlatestno checksum published
arm64Node.jsGitHub runner (setup-node)v22.23.1no checksum published
arm64Node.jsGitHub runner (setup-node)v22.23.1no checksum published
ppc64leFerretDBwekan/FerretDBv1.45.0verifiedde4518c7774d3025…
ppc64leFerretDBwekan/FerretDBv1.45.0verifiedde4518c7774d3025…
ppc64leNode.jsofficialv24.19.0verifiedc510c6ce12f07010…
ppc64leNode.jsofficialv24.19.0verifiedc510c6ce12f07010…
riscv64FerretDBwekan/FerretDBv1.45.0verified7dc2952f554e8800…
riscv64FerretDBwekan/FerretDBv1.45.0verified7dc2952f554e8800…
riscv64Node.jsunofficialv24.19.0verifiedcd1f14af28121480…
riscv64Node.jsunofficialv24.19.0verifiedcd1f14af28121480…

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.