Say that no workflow builds the Flatpak yet
NFR-COMPAT-2's table has CI building every channel, the Flatpak included. No workflow in .gitea/workflows/ builds it, and the sweep before this one records that none has been built by hand either. A status note under the table says so, so the decision and the state are not read as the same thing.
This commit is contained in:
@@ -2215,6 +2215,9 @@ public channel — and it is the position until those weights are replaced.
|
|||||||
| Android | Signed release APK, sideloaded (`docker/android/assemble-apk.sh`, the release key of 2026-09-11) — **not** Play, **not** F-Droid | CI |
|
| Android | Signed release APK, sideloaded (`docker/android/assemble-apk.sh`, the release key of 2026-09-11) — **not** Play, **not** F-Droid | CI |
|
||||||
| Windows | NSIS per-user installer cross-built from Linux (`docker/windows/`, FR-PLAT-WIN-3) | CI |
|
| Windows | NSIS per-user installer cross-built from Linux (`docker/windows/`, FR-PLAT-WIN-3) | CI |
|
||||||
|
|
||||||
|
*Status (2026-09-26).* The Flatpak row is the decision, not yet the state: no workflow under
|
||||||
|
`.gitea/workflows/` builds it, and none has been built by hand (FR-PLAT-LIN-3).
|
||||||
|
|
||||||
Two consequences the channel decision has on the requirements above it. ARCH §6.9's SAF-only
|
Two consequences the channel decision has on the requirements above it. ARCH §6.9's SAF-only
|
||||||
storage model was written because Play would reject anything else; a sideloaded build *could*
|
storage model was written because Play would reject anything else; a sideloaded build *could*
|
||||||
request broader permissions, and FR-PLAT-AND-1 keeps SAF anyway, because the design is right on
|
request broader permissions, and FR-PLAT-AND-1 keeps SAF anyway, because the design is right on
|
||||||
|
|||||||
Reference in New Issue
Block a user