Gives the Development channel a real version axis. Development-channel updates did not work at all before this; on Stable nothing changes.
For a masjid
Nothing changes on Stable. catalog.json on the stable channel is byte-identical to the previous release — same four apps, same versions, same digest-pinned images.
If you use the Development channel, this is the release that makes it work. Until now, when an app published a new development build, nothing in the catalog changed: the version number stayed the same and the image reference stayed the same. OpenMasjidOS spots an update by comparing the version it is offered against the version you have installed, so there was nothing to compare. You were never told a new build existed, and the update button had nothing to point at.
Development builds now carry their own version numbers — 0.11.0-dev.1, then -dev.2, and so on — sitting between the last release and the next one. So the App Store can tell you a new build is there, and tell you which one you are on.
What was wrong
Two faults at once, on every app. The development entry declared the same version as the released entry, so there was nothing to compare. And it pointed at a moving image label rather than a fixed one, so the catalog named one build while installing whatever that label happened to point at that day — "what you were told about" and "what you got" were two different things.
The contract now
A development entry must give the platform the same two things a release entry gives it:
- A distinct prerelease version —
X.Y.Z-dev.N, never equal to the released version, ordered between the last release and the next. - An immutable image for every service — either a digest, or a tag matching that entry's version exactly. Never a moving label.
An entry that fails either test is not published. The catalog serves that app's released version on the Development channel instead, with a warning naming the repository, so the channel stays usable while apps migrate one at a time. Three of the four apps migrated while this was being written.
Also in this release
Because the catalog now pins an exact image tag, it checks the image is actually there before publishing. One app declared a new development version minutes before its build had finished uploading, and the catalog briefly offered an entry no masjid could install. It now notices, and serves the released version until the image lands. A network problem or rate limit is treated as "don't know" rather than "missing", so a flaky connection can never demote an app.
For an app author
Your dev branch needs a prerelease version in manifest.yaml, an image published under that exact version, and a compose that references that exact tag — or a digest — for every service. Publishing a :dev alias for humans is fine; it just must not be what the compose names. Publish the image before the entry. Full details in docs/BUILDING_AN_APP.md §8b.
This supersedes guidance in v0.1.0 and v0.2.0 which said a moving :dev tag was expected on the development channel, and that equal versions across channels were fine. Both were true under the old model and are wrong now; the docs have been corrected.
Verification
Built and checked on Linux Node 20 against the live app repositories. The development channel now serves Display 0.67.0-dev.1, Donations 0.41.0-dev.1 and Students 0.46.0-dev.1, each pinning its exact version tag, with Kiosk on its released 0.10.2 until its development image is published — all four verified installable. The stable-channel build is byte-identical to the published catalog. 201 tests pass, twelve of them new. The release was also put through an independent adversarial review, which found one real documentation contradiction in the authoritative contract document; that is fixed here.