Download Latest Version
wekan-11.72-s390x.zip (286.8 MB)
Get an email when there's a new version of wekan
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-patches build 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 |
|---|---|---|---|---|---|
| amd64 | FerretDB | wekan/FerretDB | v1.49.0 | verified | 7c74941ff043f26a… |
| amd64 | Node.js | nodejs.org | v24.19.0 | verified | 14b342e71204f811… |
| arm64 | FerretDB | wekan/FerretDB | v1.49.0 | verified | 092132531555a39e… |
| arm64 | Node.js | nodejs.org | v24.19.0 | verified | 01443c1e1a29e531… |
| armhf | FerretDB | wekan/FerretDB | v1.49.0 | verified | 144404fb9793dc8e… |
| armhf | Node.js | wekan/node-patches | v24.19.0 | verified | b55350f3071b765a… |
| armv7 | FerretDB | wekan/FerretDB | v1.49.0 | verified | 144404fb9793dc8e… |
| armv7 | Node.js | wekan/node-patches | v24.19.0 | verified | 8dbe0a9aa8550ad5… |
| i386 | FerretDB | wekan/FerretDB | v1.49.0 | verified | 1f70cb1687411b2a… |
| i386 | Node.js | wekan/node-patches | v24.19.0 | verified | 3b0b3bbfe27daf58… |
| mac-arm64 | FerretDB | wekan/FerretDB | v1.49.0 | verified | 576364db59dfce3b… |
| mac-arm64 | Node.js | nodejs.org | v24.19.0 | verified | 3f1cf157479c1480… |
| ppc64le | FerretDB | wekan/FerretDB | v1.49.0 | verified | 7c61d4853d5163ad… |
| ppc64le | Node.js | nodejs.org | v24.19.0 | verified | c510c6ce12f07010… |
| riscv64 | FerretDB | wekan/FerretDB | v1.49.0 | verified | bd4912da70f5e6c1… |
| riscv64 | Node.js | unofficial-builds.nodejs.org | v24.19.0 | verified | cd1f14af28121480… |
| s390x | FerretDB | wekan/FerretDB | v1.49.0 | verified | 62900110fc3e8165… |
| s390x | Node.js | nodejs.org | v24.19.0 | verified | a4792e65962ffa0a… |
| win-arm64 | FerretDB | wekan/FerretDB | v1.49.0 | verified | 792166623e774b0a… |
| win-arm64 | Node.js | nodejs.org | v24.19.0 | verified | 8502f4a50b458d4c… |
| win64 | FerretDB | wekan/FerretDB | v1.49.0 | verified | f42c50aa84095a96… |
| win64 | Node.js | nodejs.org | v24.19.0 | verified | 57f71ab3652e797d… |
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.80 2026-08-10 WeKan ® release
In short: the Admin Panel, in the two panes v10.79 had just changed. Version is one table again rather than five: five tables sized their columns independently, so the values started at a different x in every category. The categories are rows inside one table now - bold, spanning both columns - over two equal 50% columns. Problems / Filesystem integrity drew a blank page: the one piece of its wiring that was missing was a template helper, and Blaze reads an undefined helper as false rather than complaining. The binaries below are v10.79's: nothing here rebuilds them.
| Platform | Binary | From | Version | SHA256 |
|---|---|---|---|---|
| amd64 | Node.js | nodejs.org | v24.19.0 | 14b342e71204f811bde6153be8e04b62aef63c236fef92b55f9c83154b409647 |
| amd64 | FerretDB | wekan/FerretDB | v1.48.0 | 2737687fd29a8a761cd960e45f300b68cf7b4a87d50c4cc5280bcbd42b6aa163 |
| arm64 | Node.js | nodejs.org | v24.19.0 | 01443c1e1a29e531ccad5a46fefa6df490d2189c49f7955904aecdbb0fe86fdc |
| arm64 | FerretDB | wekan/FerretDB | v1.48.0 | 5ae705dd49515a4ecd4e295c3b9aa4f3b454fad78613ec60fb99316bd7c34e3f |
| loong64 | Node.js | unofficial-builds.nodejs.org | v24.19.0 | c24f224726f2d785bd18a1fd09f5e6d1fecf0269928451a60c5da9eac8e92e68 |
| loong64 | FerretDB | wekan/FerretDB | v1.48.0 | 06ec86263455a7b598d22a87df0e044ea73ab5a3b72e96ad12ebed03c1374ac2 |
| mac-arm64 | Node.js | nodejs.org | v24.19.0 | 3f1cf157479c1480352083105e13faf9d008ede98e7e157746b6df940d197b94 |
| mac-arm64 | FerretDB | wekan/FerretDB | v1.48.0 | 9b15f4c10e473cd0a2c4feb4cb43e18042bd60c7035ec66cab3cfbe13edaabab |
| mac-x64 | Node.js | nodejs.org | v24.19.0 | d35e95230f46f6f0751df497c56622c6735e05d5e1fb1630996a005b9d328fe4 |
| mac-x64 | FerretDB | wekan/FerretDB | v1.48.0 | 4e188246dfa33bccef4cdd86701bc498b037cb3e91f579ff0dccb93aa0ef03ad |
| ppc64le | Node.js | nodejs.org | v24.19.0 | c510c6ce12f07010f771e6edb22a3fe23f4f2e6f40b1ffd4941aed0646a0d8b3 |
| ppc64le | FerretDB | wekan/FerretDB | v1.48.0 | 0400cd6dfc3d10d987a0fe80d75baa86c03c19170770fa2e602c92d558c3cfa6 |
| riscv64 | Node.js | unofficial-builds.nodejs.org | v24.19.0 | cd1f14af2812148002f58b58a5f9af512a50e3b8e8c148e0db44019dcb68edfd |
| riscv64 | FerretDB | wekan/FerretDB | v1.48.0 | d37c35af988670b9ed182b8c5966c06a06362f6c6ace6aebd93ccdfa32c9a26b |
| s390x | Node.js | nodejs.org | v24.19.0 | a4792e65962ffa0af42627aacf1122a60c3c88dbf4e4184f06820d66f9da8ba4 |
| s390x | FerretDB | wekan/FerretDB | v1.48.0 | 6c7d61fbb8c79b2e8733be8f71910f710e8c5cd25208c451bdc513c8313b0340 |
| win64 | Node.js | nodejs.org | v24.19.0 | 57f71ab3652e797d84acddc79c81cc9ff1c6ddb2a1974cdb83f00fee9bff4c73 |
| win64 | FerretDB | wekan/FerretDB | v1.48.0 | ea57e1bcd153b51d2065ab01515b21ec05d8f615444c15603ab8158b8a661dd2 |
This release reorganises the Admin Panel:
Admin Panel / Settings - the Version pane, and how it lays itself out.
Version is one table with combined category rows, over two 50% columns. Thanks to xet7.
The pane arrived at v10.79 as five tables, one per category. Five tables size their columns independently: "WeKan ® Version" made the first one's label column wide and "OS Type" made the next one's narrow, so the values started at a different x in every group and the pane read as five unrelated things. One table now, and each category is a **row** in it — a `th` with `colspan=2`, bold and start-aligned, so it says what the rows under it are about instead of being a label with an empty cell beside it. A `colgroup` of two 50% columns plus `table-layout: fixed` puts every label and every value in the same place down the whole pane; the 240px header cap the other admin tables carry is undone for this one, since its width is now stated outright and the cap would fight it. The category title keeps the table's own font size deliberately: at the pane title's size, five of them would read as five pane titles and "Version" would be lost among them. Two of the repository's own guards caught mistakes on the way, which is what they are for. The jade compile check refused `th(colspan=2)` — the Meteor jade dialect wants the value quoted, and an unquoted one is a build failure rather than a rendering difference — and the RTL check refused `text-align: left`, because the label column is on the RIGHT in Arabic and Hebrew, so it is `start`.and fixes the following bugs:
Admin Panel / Problems - a pane that drew nothing, and said nothing about it.
Problems / Filesystem integrity showed a blank page. Thanks to xet7.
The pane drew its title and then empty space, while Summary went on reporting *"7 new problems"* for it. Everything about it looked right, which is why it survived: the menu has a `report-integrity` entry, clicking it is handled, the handler sets `tmpl.showIntegrity`, and the template has `else if showIntegrity.get` with an integrity event stream under it. The missing piece was the **helper**. `showIntegrity()` was never added beside `showDatabase()` and the eight others, and in Blaze **an undefined helper is not an error — it is falsy**. So the branch never ran, the page was blank, and nothing anywhere said why. The guard added with it is the class rather than this one pane: every `show*.get` branch in a settings template must have a helper of that name in that template's own `.js`, and a `ReactiveVar` behind it. The templates are FOUND rather than listed, so a pane added later is covered without editing the test.The snap - what it does when it cannot read the database it was upgraded onto.
A database this snap cannot read stops and says so, instead of serving 502 forever. Thanks to Philippe-Bentegeac, JDeepix, imlit and xet7.
A snap upgraded onto a database left by a **MongoDB 4.x or 5.x** snap served 502 Bad Gateway indefinitely, with the reason only in `snap logs`: This version of MongoDB is too recent to start up on the existing data files. Try MongoDB 4.2 or earlier. The snap carries **two** readers — mongod 7, the server it runs, and the MongoDB 3.2 tools for a 6.09-era database — and nothing in between, so 4.x data opens in neither. What the code did then is the one thing that cannot work: the migration found that neither reader could open it and handed back to `mongodb-control`, which started mongod, which failed the same way, which re-ran the migration — three times by its own counter — and then exited for snapd to restart. Nothing in that loop can succeed, because reading those files needs a binary the snap does not have. **It stops now.** The migration tells "no reader for this vintage" from "unreadable or corrupt" by mongod's own words, records the version mongod named as still able to read the data, pauses auto-migration and exits **0** — zero, because snapd restarts a failing service forever and no restart can help here. `mongodb-control` will not start a mongod it knows cannot start, and WeKan serves an explanatory page on the web port, both at startup and from inside the database wait loop, so an instance already waiting switches over without a restart. The page names the MongoDB version that can still read the files and gives the two ways forward — go back to the revision that worked, or dump with a MongoDB that can read it and restore into this version — says plainly that **nothing was changed** and that attachments and avatars are files on disk, and drops the auto-refresh and the spinner the other two maintenance pages carry: this is a stop, not a wait, and the page should not promise that something is happening. Nothing is deleted or modified on this path: the source data is exactly as it was, the marker file is the only thing written, and removing it lets the snap try again. The snap documentation gains the section an admin searching for that mongod line will find, with the commands. The test covers the wiring in all three scripts and then RUNS the page — it is standalone Node with no dependencies — to check what an admin actually sees: 503, the version, "untouched", both remedies, no refresh, no spinner.A third MongoDB reader, so a 4.x database migrates instead of stopping. Thanks to Philippe-Bentegeac, JDeepix, imlit and xet7.
The entry above stopped the crash loop and explained it. This removes the reason for it in the case that was actually reported. A MongoDB server only starts on data whose `featureCompatibilityVersion` is at most one major behind it, so what the snap can READ is decided by which servers it carries: mongod 7 (FCV 6.0, 7.0) and the MongoDB 3.2 tools (3.2). Everything in between was unreadable — and the WeKan snap has shipped 3.6, 4.0, 4.2, 4.4 and 5.0 over the years. The reported error names the gap exactly: *"Try MongoDB 4.2 or earlier"*, which is FCV 4.0. **mongod 4.2 is now bundled as a third reader**, used only to read the old data during a migration and never as the running database. It opens FCV 4.0 and 4.2, and the modern importer reads it with the bundled driver, which supports servers from 4.2 up — the same importer that reads a 6/7 source, not a second copy of it. The probes run newest-first: 7, then 4.2, then the 3.2 tools, then the page. **amd64 and arm64 only.** MongoDB publishes no 4.2 for the others, and they have been FerretDB from their first boot, so there is nothing there to migrate from. **It carries its own OpenSSL 1.1.** The 4.2 build links `libssl.so.1.1` and `libcrypto.so.1.1`, and core24 is Ubuntu 24.04, which ships OpenSSL 3 — without them the binary does not even load. Both come from one Debian `libssl1.1` package, staged beside the binary and put on `LD_LIBRARY_PATH` exactly as the 3.2 tools already are, with the filename resolved by listing the pool rather than pinned, because point releases roll and a pinned name 404s the day they do. Optional by design: every failure in that part — download, checksum, OpenSSL, or the binary not running — ends it with a message and no binary, and the migration simply does not find one. A release is never failed over a migration aid. Verified as far as a machine without a snap allows: mongod 4.2.25 aarch64 was downloaded, staged with the Debian libssl1.1 and RUN — *"db version v4.2.25, OpenSSL version: OpenSSL 1.1.1w"* — then started on a dbpath, forked and listened on a port. That is the whole mechanism, on a 2026 system. The build repeats the check and unstages the binary if it fails. Still unreadable, and still answered by the page rather than a migration: 3.4, 3.6, 4.4 and 5.0. Bundling mongod 5.0 beside this one would close 4.4 and 5.0 the same way, at the same cost in size.and improves the translations:
Translations - the new strings, and the languages that keep the English placeholder.
The Version pane's new strings, translated into 113 languages. Thanks to xet7.
The pane's five category labels and the packaging row arrived in English only, so every other language showed them in English. Three of the six needed translating at all: **Platform**, **package** ("Package") and **OS**. `Database` was already translated in 131 languages — the key existed before and this revived it — and **Meteor** and **Node** are product names that stay as they are in every language, which is also why the filler ignores a value equal to the English source. Translated directly, with no external service, using each language's own existing strings as the reference. Its `OS_Type` and `OS_Platform` show the form that language's translators use — *"Typ des Betriebssystems"*, *"Tipo SO"*, *"Тип ОС"*, *"Käyttöjärjestelmän tyyppi"* — so OS is `Betriebssystem` in German, `SO` in Italian and Portuguese, `ОС` in Russian and `Käyttöjärjestelmä` in Finnish, rather than one spelling imposed on all of them. Two files were deliberately NOT copied from: Greek's `OS_Type` and `OS_Platform` hold Italian, and Korean's hold Japanese. Propagating that would have spread somebody else's mistake into three more strings, so those two got proper Greek and Korean instead. Applied through `fill-translations.mjs --apply`, which writes **only** into a placeholder, so no human translation could be overwritten even by accident — and the diff shows it: 292 changed lines across 106 files, every one of them `Platform`, `package` or `OS`. Key order and indentation are unchanged, every file still parses, and `verify-human-preference.mjs` passes 10/10. **40 files keep the English placeholder on purpose** — ace, ary, br, gu-IN, ig, km, mn, oc, or_IN, pa, tk_TM, tlh, ug, ve, vl-SS, vo, wa, wo, xh, yi, yo, zgh, zu and the `en-*` variants, which are English by design. A placeholder that says so is better than a translation nobody can stand behind, and Transifex can still replace any of them with a human one: nothing here is pushed there.Thanks to above GitHub users for their contributions and translators for their translations.
