# Distribution channel inventory (the "visibility matrix"). # # One entry per place users can obtain LibreDB Studio. Human-maintained: # scripts/distribution-check.mjs READS this file and reports drift against # package.json - it never writes version numbers into it. Schema, tier and # SLA definitions, and maintenance rules (including when to update # last_bump_pr) live in docs/DISTRIBUTION.md ("Channel inventory and drift # check"). # # Field summary: # id/name/status/tier identity; status: live | pending | deprecated # kind the technical shape of the artefact (what it # literally is), independent of category (the audience-facing # bucket several kinds can share): one of release-assets | # container-image | package-registry | helm-chart | # package-manager | os-package | one-click-template | # paas-template | deploy-button | operator-catalog | # partner-catalog | curated-catalog | marketplace # category business bucket for docs/CHANNELS.md: # registries-releases | containers | kubernetes-operators | # package-managers | os-desktop | paas-catalogs | # deploy-recipes | cloud-marketplaces # platforms REQUIRED, non-empty list. Rendered and counted in # this canonical order in docs/CHANNELS.md: # linux | macos | windows | container | kubernetes | cloud # runtime REQUIRED. Who provides the Node.js the server runs # on, which is what decides whether raising # `engines.node` is a breaking change for this # channel's users (issue #326): # user_supplied - the user's own `node` executes # the payload, so the floor is theirs to meet. # channel_supplied - the channel provides it: # bundled in the artefact (image, snap, deb/rpm, # Windows zip, Flatpak, Tauri sidecar), inherited # from an image a template deploys, or installed as # a declared dependency (Homebrew node@24). # Not derivable from `kind`: deb/rpm are os-package # and bundle a private Node, npm is package-registry # and does not. # short_name optional; the display name docs/CHANNELS.md uses when # `name` is too long to scan. Falls back to `name`. # update.method ci_publish | commit | upstream_pr | manual_ui # update.sla every_release | minor_plus | major_only | on_demand # update.ci_enabled REQUIRED on, and allowed ONLY on, the switchable # channels (docker-hub-mirror, homebrew, snap, # winget, chocolatey): may release CI publish this # channel? The release workflow reads it, so turning # a channel off here is the whole switch - no secret # to delete, no workflow edit. The core release path # (github-release, docker-ghcr, npm, helm) and the # required release assets have no flag on purpose. # links tracking_issue / first_pr / last_bump_pr (nullable # until the first post-listing bump) / catalog / # upstream_repo / docs / get (user-facing "where do I # get it"; docs/CHANNELS.md resolves it as # get > catalog > upstream_repo, except a deprecated # channel renders no link at all, whatever these # fields hold) # pin.strategy local_file | remote_file | probe | none # pin.probe required when strategy == probe; one of the probe ids # defined in scripts/distribution-check.mjs # pin.urls required when strategy == probe; URL template(s) the # probe uses (see the probe's requiredUrls) # pin.architectures required for the snap-store-channel probe; list of # architectures to measure independently # pin.extract regex with ONE capture group; required for # local_file / remote_file; all matches in a source # must agree (ambiguity is reported, never resolved # to the first hit) channels: # ---- Tier 0: core registries, published directly by release CI ---------- - id: github-release name: GitHub Releases (standalone tarballs, deb/rpm, snap assets) short_name: GitHub Releases status: live category: registries-releases platforms: [linux, macos, windows] runtime: user_supplied tier: 0 kind: release-assets update: method: ci_publish sla: every_release links: catalog: https://github.com/libredb/libredb-studio/releases docs: docs/DISTRIBUTION.md pin: strategy: remote_file url: https://api.github.com/repos/libredb/libredb-studio/releases/latest extract: '"tag_name":\s*"(\d+\.\d+\.\d+)"' note: Probes the latest-release API; confirms the draft-first publish actually landed. - id: docker-ghcr name: Docker image (GHCR, canonical) short_name: Docker image (GHCR) status: live category: containers platforms: [container] runtime: channel_supplied tier: 0 kind: container-image update: method: ci_publish sla: every_release links: catalog: https://github.com/libredb/libredb-studio/pkgs/container/libredb-studio pin: strategy: probe probe: ghcr-tag-digest urls: token: https://ghcr.io/token?service=ghcr.io&scope=repository:libredb/libredb-studio:pull manifest: https://ghcr.io/v2/libredb/libredb-studio/manifests/{ref} note: Compares the image :latest resolves to against the released version tag. Anonymous pull token, no secret, so the probe also works from a fork. - id: docker-hub-mirror name: Docker Hub mirror (discoverability only) short_name: Docker Hub mirror status: live category: containers platforms: [container] runtime: channel_supplied tier: 0 kind: container-image update: method: ci_publish sla: every_release ci_enabled: true links: catalog: https://hub.docker.com/r/libredb/libredb-studio pin: strategy: probe probe: dockerhub-tag-digest urls: tag: https://hub.docker.com/v2/repositories/libredb/libredb-studio/tags/{ref} note: Mirror of GHCR; immutable-tag rules must stay semver-only. The push is secret-gated and skips silently, so an absent version tag here is how an expired DOCKER_HUB_TOKEN becomes visible. - id: npm name: npm package @libredb/studio (library + npx launcher) short_name: npm @libredb/studio status: live category: registries-releases platforms: [linux, macos, windows] runtime: user_supplied tier: 0 kind: package-registry update: method: ci_publish sla: every_release links: tracking_issue: https://github.com/libredb/libredb-studio/issues/110 first_pr: https://github.com/libredb/libredb-studio/pull/122 catalog: https://www.npmjs.com/package/@libredb/studio pin: strategy: remote_file url: https://registry.npmjs.org/-/package/@libredb/studio/dist-tags extract: '"latest":\s*"(\d+\.\d+\.\d+)"' note: Probes the npm dist-tags endpoint; confirms npm-publish.yml actually landed. # ---- Tier 1: packaged formats owned by this repo, CI-published ---------- - id: helm name: Helm chart (libredb.org repo + GHCR OCI + ArtifactHub) short_name: Helm chart status: live category: kubernetes-operators platforms: [kubernetes] runtime: channel_supplied tier: 1 kind: helm-chart update: method: ci_publish sla: every_release links: tracking_issue: https://github.com/libredb/libredb-studio/issues/138 first_pr: https://github.com/libredb/libredb-studio/pull/44 catalog: https://artifacthub.io/packages/helm/libredb-studio/libredb-studio docs: docs/HELM_CHART.md pin: strategy: local_file files: - charts/libredb-studio/Chart.yaml extract: 'appVersion: "(\d+\.\d+\.\d+)"' note: Enforcement lives in the required chart:check CI gate (#138); this row is visibility. - id: homebrew name: Homebrew tap (libredb/tap/libredb-studio) short_name: Homebrew tap status: live category: package-managers platforms: [macos, linux] runtime: channel_supplied tier: 1 kind: package-manager update: method: ci_publish sla: every_release ci_enabled: true links: tracking_issue: https://github.com/libredb/libredb-studio/issues/111 first_pr: https://github.com/libredb/libredb-studio/pull/122 upstream_repo: https://github.com/libredb/homebrew-tap pin: strategy: remote_file url: https://raw.githubusercontent.com/libredb/homebrew-tap/main/Formula/libredb-studio.rb extract: 'version "(\d+\.\d+\.\d+)"' note: Confirms the release-CI tap push actually landed. - id: snap name: Snap Store (stable channel, amd64+arm64) short_name: Snap Store status: live category: package-managers platforms: [linux] runtime: channel_supplied tier: 1 kind: package-manager update: method: ci_publish sla: every_release ci_enabled: true links: tracking_issue: https://github.com/libredb/libredb-studio/issues/113 first_pr: https://github.com/libredb/libredb-studio/pull/177 catalog: https://snapcraft.io/libredb-studio pin: strategy: probe probe: snap-store-channel architectures: - amd64 - arm64 urls: info: https://api.snapcraft.io/v2/snaps/info/libredb-studio note: Reads the stable channel of each architecture separately, so one lagging build is drift rather than a pass. Edge may legitimately differ from stable and is ignored. - id: linux-deb-rpm name: Linux .deb / .rpm packages (release assets) short_name: Linux .deb / .rpm status: live category: os-desktop platforms: [linux] runtime: channel_supplied tier: 1 kind: os-package update: method: ci_publish sla: every_release links: tracking_issue: https://github.com/libredb/libredb-studio/issues/112 first_pr: https://github.com/libredb/libredb-studio/pull/122 get: https://github.com/libredb/libredb-studio/releases/latest pin: strategy: none note: Built by nfpm from the tag in release-artifacts.yml; nothing to drift. - id: appimage # Quoted: an unquoted scalar containing ": " is a YAML mapping, not a string. name: "Desktop app (release assets: AppImage and GUI .deb, x64 + arm64)" short_name: Desktop app (AppImage, .deb) status: live category: os-desktop platforms: [linux] runtime: channel_supplied tier: 1 kind: release-assets update: method: ci_publish sla: every_release links: tracking_issue: https://github.com/libredb/libredb-studio/issues/232 first_pr: https://github.com/libredb/libredb-studio/pull/235 get: https://github.com/libredb/libredb-studio/releases/latest docs: desktop/README.md pin: strategy: none note: Both artifacts come per arch out of the one desktop-appimage job and are required by publish-release, so they cannot drift from the tag - hence no pin. The AppImage has shipped since 0.9.60 and the GUI .deb since 0.9.62. The AppImage is also what the in-repo Flatpak manifest repacks in flatpak-smoke.yml (packaging/flatpak, dormant - see the flathub channel); the GUI .deb (libredb-studio-desktop__.deb, distinct from the headless server package) is what FlatPark pins as extra-data. # ---- Tier 2: LibreDB-owned copies and listings, bumped by hand ---------- - id: railway-template name: Railway one-click template status: live category: paas-catalogs platforms: [cloud] runtime: channel_supplied tier: 2 kind: paas-template update: method: manual_ui sla: on_demand links: tracking_issue: https://github.com/libredb/libredb-studio/issues/174 first_pr: https://github.com/libredb/libredb-studio/pull/67 catalog: https://railway.com/deploy/libredb-studio docs: deploy/railway/PUBLISH.md pin: strategy: local_file files: - deploy/railway/template.json - deploy/railway/README.md - deploy/railway/PUBLISH.md extract: 'libredb-studio:(\d+\.\d+\.\d+)' note: The published template is edited in the Railway dashboard; these three files must move together. - id: koyeb-deploy-button name: Koyeb deploy button (repo README) short_name: Koyeb deploy button status: live category: deploy-recipes platforms: [cloud] runtime: channel_supplied tier: 2 kind: deploy-button update: method: commit sla: on_demand links: get: https://github.com/libredb/libredb-studio/tree/main/deploy/koyeb docs: deploy/koyeb/README.md pin: strategy: none note: The button deploys ghcr.io latest by design; there is no version pin. - id: fly-io name: Fly.io launch config (repo fly.toml) short_name: Fly.io launch config status: live category: deploy-recipes platforms: [cloud] runtime: channel_supplied tier: 2 kind: paas-template update: method: commit sla: on_demand links: tracking_issue: https://github.com/libredb/libredb-studio/issues/218 first_pr: https://github.com/libredb/libredb-studio/pull/219 get: https://github.com/libredb/libredb-studio/blob/main/fly.toml docs: docs/FLY.md pin: strategy: local_file files: - fly.toml extract: 'libredb-studio:(\d+\.\d+\.\d+)' note: Users deploy straight from the repo file; bump the tag here on release when convenient. - id: render name: Render Blueprint (repo render.yaml) short_name: Render Blueprint status: live category: deploy-recipes platforms: [cloud] runtime: channel_supplied tier: 2 kind: paas-template update: method: commit sla: on_demand links: get: https://github.com/libredb/libredb-studio/blob/main/render.yaml docs: docs/DISTRIBUTION.md pin: strategy: none note: Render builds from the repo Dockerfile (render.yaml dockerfilePath) on push, so there is no image tag to pin - the deployed version tracks whatever main builds. Like fly.toml, render.yaml is auto-detected at the repo root, so users deploy straight from the repo Blueprint. - id: unraid-ca name: Unraid Community Applications (libredb/unraid-templates) short_name: Unraid Community Apps status: live category: paas-catalogs platforms: [container] runtime: channel_supplied tier: 2 kind: one-click-template update: method: commit sla: on_demand links: tracking_issue: https://github.com/libredb/libredb-studio/issues/283 catalog: https://ca.unraid.net/apps/libredb-studio-0a5x41a1cy1kay upstream_repo: https://github.com/libredb/unraid-templates docs: docs/DISTRIBUTION.md pin: strategy: remote_file url: https://raw.githubusercontent.com/libredb/unraid-templates/main/templates/libredb-studio.xml extract: 'libredb-studio:(\d+\.\d+\.\d+)' note: The container template is LibreDB-owned (libredb/unraid-templates), so a version bump is a commit in THAT repo - not a PR here and not an upstream PR - which is why this is tier 2 with a remote_file pin rather than local_file. Community Applications only serves what its own periodic catalog build picked up, so a bump reaches users one CA build after the commit. Submitted via ca.unraid.net/submit on 2026-08-04 and auto-approved (a non-duplicate Docker app with no plugin needs no human review). The `container` platform is deliberate and not a stand-in for cloud - the user installs a Docker container on their own Unraid server. # ---- Tier 3: upstream community catalogs, bumped via PR ----------------- - id: caprover-official name: CapRover official one-click apps short_name: CapRover official status: live category: paas-catalogs platforms: [cloud] runtime: channel_supplied tier: 3 kind: one-click-template update: method: upstream_pr sla: on_demand links: tracking_issue: https://github.com/libredb/libredb-studio/issues/56 first_pr: https://github.com/caprover/one-click-apps/pull/1303 upstream_repo: https://github.com/caprover/one-click-apps docs: deploy/caprover/README.md pin: strategy: remote_file url: https://raw.githubusercontent.com/caprover/one-click-apps/master/public/v4/apps/libredb-studio.yml extract: "defaultValue: '(\\d+\\.\\d+\\.\\d+)'" note: The single CapRover row. A LibreDB-owned 3rd-party repo (libredb/caprover-one-click-apps) served the app while this submission was in review and was retired once it merged; it had its own inventory entry until that duplicated CapRover in the coverage matrix as one live and one dead route to the same platform, with the dead one's URL no longer published. Its record lives in deploy/caprover/README.md, which is where a maintainer bumping the template already looks. Users install from the official catalog only - no third-party repo to add. - id: dokploy name: Dokploy template catalog status: live category: paas-catalogs platforms: [cloud] runtime: channel_supplied tier: 3 kind: paas-template update: method: upstream_pr sla: on_demand links: tracking_issue: https://github.com/libredb/libredb-studio/issues/171 first_pr: https://github.com/Dokploy/templates/pull/931 catalog: https://templates.dokploy.com upstream_repo: https://github.com/Dokploy/templates docs: deploy/dokploy/README.md pin: strategy: remote_file url: https://raw.githubusercontent.com/Dokploy/templates/main/blueprints/libredb-studio/docker-compose.yml extract: 'libredb-studio:(\d+\.\d+\.\d+)' note: Bump from 0.9.27 to the current release is tracked in issue 175. - id: cosmos name: Cosmos servapp marketplace status: live category: paas-catalogs platforms: [cloud] runtime: channel_supplied tier: 3 kind: one-click-template update: method: upstream_pr sla: on_demand links: tracking_issue: https://github.com/libredb/libredb-studio/issues/172 first_pr: https://github.com/azukaar/cosmos-servapps-official/pull/218 upstream_repo: https://github.com/azukaar/cosmos-servapps-official docs: deploy/cosmos/README.md pin: strategy: remote_file url: https://raw.githubusercontent.com/azukaar/cosmos-servapps-official/master/servapps/LibreDB-Studio/cosmos-compose.json extract: 'libredb-studio:(\d+\.\d+\.\d+)' - id: kubero name: Kubero template catalog status: live category: paas-catalogs platforms: [cloud] runtime: channel_supplied tier: 3 kind: paas-template update: method: upstream_pr sla: on_demand links: tracking_issue: https://github.com/libredb/libredb-studio/issues/173 first_pr: https://github.com/kubero-dev/kubero/pull/754 catalog: https://www.kubero.dev/templates upstream_repo: https://github.com/kubero-dev/kubero docs: deploy/kubero/README.md pin: strategy: remote_file url: https://raw.githubusercontent.com/kubero-dev/kubero/main/services/libredb-studio/app.yaml extract: 'ghcr\.io/libredb/libredb-studio\s+tag:\s*(\d+\.\d+\.\d+)' - id: sealos name: Sealos App Store template status: live category: paas-catalogs platforms: [cloud] runtime: channel_supplied tier: 3 kind: one-click-template update: method: upstream_pr sla: on_demand links: tracking_issue: https://github.com/libredb/libredb-studio/issues/276 first_pr: https://github.com/labring-actions/templates/pull/739 catalog: https://sealos.io/products/app-store/libredb-studio upstream_repo: https://github.com/labring-actions/templates docs: docs/DISTRIBUTION.md pin: strategy: remote_file url: https://raw.githubusercontent.com/labring-actions/templates/kb-0.9/template/libredb-studio/index.yaml extract: 'libredb-studio:(\d+\.\d+\.\d+)' note: Sealos app-store templates live in labring-actions/templates (labring is the company behind Sealos) and go in as a direct template PR - no upstream issue first. That repo's default branch is `kb-0.9`, NOT main or master, so both the pin URL above and any bump PR must target it; a raw.githubusercontent URL on `main` 404s, and `master` carries a copy that can lag. The template pins the image in TWO places - the StatefulSet's `originImageName` annotation and the container `image` - so the shared all-matches-must-agree rule is what catches a half-finished bump here. Deploys SQLite on a 1 GiB PVC by default, with KubeBlocks-managed PostgreSQL as an opt-in storage backend, and ships AUTH_BOOTSTRAP=off so the deployment starts in strict mode. - id: operatorhub-community name: OperatorHub / OpenShift community operator catalogs short_name: OperatorHub / OpenShift status: pending category: kubernetes-operators platforms: [kubernetes] runtime: channel_supplied tier: 3 kind: operator-catalog update: method: upstream_pr sla: every_release links: tracking_issue: https://github.com/libredb/libredb-studio/issues/152 first_pr: https://github.com/libredb/libredb-studio/pull/156 upstream_repo: https://github.com/redhat-openshift-ecosystem/community-operators-prod docs: docs/DISTRIBUTION.md pin: strategy: local_file files: - operator/bundle/manifests/libredb-studio-operator.clusterserviceversion.yaml extract: 'libredb-studio-operator:(\d+\.\d+\.\d+)' note: Catalog submissions (k8s-operatorhub + community-operators-prod) start after the operator PR lands; the committed bundle is the source for both, with community-operators-prod contributed in FBC mode (fbc.enabled plus per-OCP-version catalog_mapping in ci.yaml). FBC releases in two upstream PRs - bundle first, then the rendered catalogs - and that second PR is only bot-created when the bundle directory ships a release-config.yaml, so every release must include one. # ---- Tier 4: partner and curated catalogs (not self-serve) -------------- - id: rancher-partner name: Rancher Partner Charts status: pending category: kubernetes-operators platforms: [kubernetes] runtime: channel_supplied tier: 4 kind: partner-catalog update: method: upstream_pr sla: on_demand links: tracking_issue: https://github.com/libredb/libredb-studio/issues/166 first_pr: https://github.com/rancher/partner-charts/pull/1158 upstream_repo: https://github.com/rancher/partner-charts pin: strategy: none note: Awaiting certification; pin strategy decided once the listing exists. - id: koyeb-catalog name: Koyeb One-Click Apps catalog (curated by Koyeb) short_name: Koyeb One-Click Apps catalog status: pending category: cloud-marketplaces platforms: [cloud] runtime: channel_supplied tier: 4 kind: curated-catalog update: method: manual_ui sla: on_demand links: catalog: https://www.koyeb.com/deploy docs: deploy/koyeb/CATALOG_SUBMISSION.md pin: strategy: none - id: digitalocean name: DigitalOcean Marketplace status: live category: cloud-marketplaces platforms: [cloud] runtime: channel_supplied tier: 4 kind: marketplace update: method: manual_ui sla: on_demand links: tracking_issue: https://github.com/libredb/libredb-studio/issues/72 first_pr: https://github.com/libredb/libredb-studio/pull/210 catalog: https://marketplace.digitalocean.com/apps/libredb-studio docs: deploy/digitalocean/README.md pin: strategy: none - id: winget name: winget community repository (LibreDB.Studio) short_name: winget status: live category: package-managers platforms: [windows] runtime: channel_supplied tier: 4 kind: package-manager update: method: ci_publish sla: every_release # The first listing merged 2026-07-31, so wingetcreate update now has a # manifest to carry forward and every release submits an update PR. ci_enabled: true links: tracking_issue: https://github.com/libredb/libredb-studio/issues/114 first_pr: https://github.com/microsoft/winget-pkgs/pull/402985 catalog: https://github.com/microsoft/winget-pkgs/tree/master/manifests/l/LibreDB/Studio upstream_repo: https://github.com/microsoft/winget-pkgs docs: docs/DISTRIBUTION.md pin: strategy: probe probe: winget-max-version urls: versions: https://api.github.com/repos/microsoft/winget-pkgs/contents/manifests/l/LibreDB/Studio note: Listed since 0.9.59 (winget install LibreDB.Studio). winget publishes no floating "latest" document - the contents listing enumerates every published version - so the highest version it enumerates is the served state. A regex pin cannot express that (all matches in a source must agree), which is why this is a probe. The release job's own pre-check (package listed / version already merged / update PR already open) remains the publish-time guard. - id: chocolatey name: Chocolatey community repository (libredb-studio) short_name: Chocolatey status: pending category: package-managers platforms: [windows] runtime: channel_supplied tier: 4 kind: package-manager update: method: ci_publish sla: every_release # push.chocolatey.org answers 403 for EVERY version while an account's # first submission is unapproved, which failed the 0.9.60 and 0.9.61 # release runs after the releases themselves had published fine. ci_enabled: false links: tracking_issue: https://github.com/libredb/libredb-studio/issues/114 catalog: https://community.chocolatey.org/packages/libredb-studio docs: docs/DISTRIBUTION.md pin: strategy: none note: win32 zip ships in every release since 0.9.59. CI packs and pushes via the choco container (CHOCO_API_KEY gate) once ci_enabled is flipped; the first push (0.9.59) is in human moderation. When approved, set ci_enabled true, flip to live, add a community-API pin. - id: flathub name: Flathub community catalog (org.libredb.Studio) short_name: Flathub status: deprecated category: package-managers platforms: [linux] runtime: channel_supplied tier: 4 kind: package-manager update: method: upstream_pr sla: on_demand links: tracking_issue: https://github.com/libredb/libredb-studio/issues/232 upstream_repo: https://github.com/flathub/flathub first_pr: https://github.com/flathub/flathub/pull/9538 docs: packaging/flatpak/README.md pin: strategy: none note: Not shipped, and not being pursued. The submission (flathub/flathub#9538) was declined on 2026-07-30 under Flathub's generative AI policy - the reviewer's position was that developing with an AI assistant disqualifies the app, and the PR carries their AI Slop label. We closed it ourselves rather than argue the point; the closing comment, which leaves the verifiable maintenance record on the thread, is at https://github.com/flathub/flathub/pull/9538#issuecomment-5136879185. Linux desktop users get the same app id from the flatpark channel, which is live - route every Flatpak instruction there. packaging/flatpak stays in the tree because the manifest still renders and flatpak-smoke.yml still builds it, but a resubmission would additionally have to be built from source (the AppImage repack is a second, independent blocker), so treat this as dormant rather than as work in progress. - id: flatpark name: FlatPark signed Flatpak remote (org.libredb.Studio) short_name: FlatPark (Flatpak) status: live category: package-managers platforms: [linux] runtime: channel_supplied tier: 4 kind: package-manager update: method: upstream_pr sla: every_release links: tracking_issue: https://github.com/libredb/libredb-studio/issues/241 upstream_repo: https://github.com/flatpark/flatpark first_pr: https://github.com/flatpark/flatpark/pull/158 catalog: https://flatpark.org/ docs: packaging/flatpark/README.md pin: strategy: none note: Repackages the GUI .deb as Flatpak extra-data - the artifact is fetched on the user's machine at install time, not built by FlatPark, and AppImages are not accepted there. The descriptor set is staged in packaging/flatpark and copied into a flatpark/flatpark fork as registry/org.libredb.Studio. Live since 0.9.62 (flatpark/flatpark#158 merged 2026-07-30), carrying the developer-approved flag - LibreDB packages its own app. FlatPark's bot now re-pins every release from resolve-update.sh, so the staged copy drifts by design and must stay out of release gates; a released version reaching the catalog is their CI's job, not ours, which is why there is no pin here. Sequencing question settled 2026-07-30 - FlatPark asks that an app not already be on Flathub, and the Flathub submission was declined, so this is now the only Flatpak channel and there is nothing to revisit.