v0.2.0 — No more dev-channel downgrades

Fixes the Development channel offering app downgrades, and stops the dev catalog going stale again.

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 images.

If you use the Development channel, this is worth having. For about half a day, switching to Development offered to move your apps backwards — Display 0.66.1 → 0.66.0, Donations 0.40.1 → 0.40.0, Kiosk 0.10.2 → 0.10.1 — and the newest Students work wasn't reachable at all. That is fixed, and the dev channel now refreshes hourly instead of daily.

What went wrong

The dev catalog was built once and then never rebuilt. Nothing was wrong with any app: every app's dev branch was already up to date. The catalog only rebuilt itself when this repository's own dev branch was pushed, while the three app releases were recorded directly on main — so the dev channel simply kept serving what it had built that morning.

The fix, in two parts

A freshness floor. The dev channel now compares each app's development version against its released version and publishes whichever is newer. If an app's dev branch has fallen behind its own release — normally because a fix went straight to the release and was never merged back — the dev channel quietly serves the released version for that app instead, and the build says so. The dev channel therefore cannot offer an older version than stable, by construction rather than by good fortune.

An assertion behind it. After the catalog is built, every entry is checked against its released version and the build fails outright if any is behind. This mirrors the existing rule in the other direction: the stable channel refuses to publish development content, and the development channel refuses to publish anything older than stable.

Prevention and detection deliberately: failing the build alone would have left the stale catalog published, which was the original problem.

Staying fresh

• The rebuild runs hourly rather than daily.
• A stable release now also rebuilds the dev channel — a release invalidates the dev catalog, because apps without a dev branch fall back to their release and every dev entry is floored at its released version.
• App repositories can trigger a rebuild immediately when they push to their dev branch; docs/BUILDING_AN_APP.md §8b has the recipe.

For an app author

Keep your dev branch at or ahead of your release. If it declares an older version, the catalog will not publish it — it serves your release on the dev channel instead, with a warning — because publishing it would offer a masjid a downgrade.

You do not need a different version number on dev. OpenMasjidOS compares channels rather than version numbers, so the same version on both branches is fine and is normal for a moving :dev tag. (This corrects guidance in v0.1.0 which said versions should differ.)

Verification

Built and checked on Linux Node 20 against the live app repositories. The dev channel now resolves Display 0.66.1, Donations 0.40.1, Kiosk 0.10.2 and Students 0.47.0 — at or ahead of stable for every app. Both new layers were made to fire deliberately: pointing an app's dev reference at an older tag produced a fallback to the release rather than a downgrade, and removing the floor made the build fail as intended. The stable-channel build is byte-identical to the published catalog. 189 tests pass, nine of them new, including one that asserts this exact regression app by app.