Skip to content

v0.1.0 — Two update channels

Choose a tag to compare

View all tags
@hasan-ismail hasan-ismail released this 05 Aug 15:17
· 20 commits to main since this release
v0.1.0
046a9b9
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

The first tagged release of the OpenMasjidAPPS catalog. It carries the two update channels — stable and dev — and the tooling that keeps them apart.

For a masjid

Nothing you install changes in this release. catalog.json is byte-identical to what it was before, and the same four apps are listed: OpenMasjid Display, Donations, Kiosk and Students.

What is new is that OpenMasjidOS's Update Channel setting now has a catalog to point at. Stay on Stable and nothing about your masjid changes. Switch to Development and your App Store lists the same apps built from each app's dev branch — useful for testing, and not what you want on the screens in the prayer hall.

For an app author

registry.yaml now holds both channel addresses per app:

  - id: kiosk
    repo: OpenMasjid-Solutions/OpenMasjidKiosk
    ref: v0.10.1                    # stable — a release tag, never a branch
    commit: 1c9f3c55…                # the immutable SHA that tag is at
    dev_ref: dev                     # dev channel — a moving branch, by design
  • ref must now be a release tag or a commit SHA. A branch there is a build failure — it would make the stable catalog silently follow a moving branch. Branches belong in dev_ref.
  • To ship on the dev channel your repo needs a dev branch, a :dev image published from it, that tag referenced in the dev branch's compose, and dev_ref on your registry entry. Miss any of it and you still appear on the dev channel — the build falls back to your stable release.
  • Open PRs against dev, not main.

Full contract: docs/BUILDING_AN_APP.md §8b and CLAUDE.md §3b.

The rule the tooling exists to enforce

main/catalog.json is fetched directly by every masjid with no build or deploy step in between, so a dev image landing there would be live immediately. Three independent gates prevent it: the build fails on a dev ref or dev-tagged image in the stable channel; lint fails when a committed catalog carries dev images and the channel is stable (it runs on pull requests using the base branch, so a dev → main PR is red until its catalog is rebuilt); and CI publishes one channel per matrix leg, each asserting HEAD matches its branch and pushing with an explicit refspec.

Also in this release

  • CI actions bumped — actions/checkout v7.0.1, actions/setup-node v7.0.0, clearing the Node 20 deprecation warning. Both stay SHA-pinned.
  • Dependabot points at dev, so routine bumps no longer need a release to land.
  • README rewritten to match the actual feature set: the app list, the full Fabric opt-in surface (sso, notifications, stripe, domain, email, alerts, the app-to-app broker, tunnel, https), what the build refuses, and the npm scripts.
  • Branching policy written down: dev is the working branch, main moves only for a release.

Verification

Built and checked on Linux Node 20, the version CI uses: 180 tests, lint clean as the stable channel, the main-channel rebuild byte-identical to the published catalog, and the dev channel resolving all four apps to their dev branch and :dev image. The release also went through an adversarial review — four independent reviewers, 12 findings, all refuted under verification; the one real residual it surfaced (a release-branch lint gap) is fixed here.

Assets 2
Loading