平台支持
Niobium 把它构建的平台分为三个层级。层级说明项目在该平台上承诺什么；这些承诺目前是否兑现，记录在状态与平台上，那是唯一报告结果的页面。
这份列表刻意保持简短。Niobium 由一个人在业余时间维护，背后没有公司资源（关于本项目），而每个一级平台都会让每次变更多出构建、测试和发布的时间。
| 层级 | 每次变更都构建 | 发布前在真实系统上测试 | 可以阻塞发布 | 修复 |
|---|---|---|---|---|
| 一级（Tier 1） | 是 | 必须 | 是 | 最优先 |
| 二级（Tier 2） | 是 | 尽力而为 | 否 | 时间允许时 |
| 三级（Tier 3） | 否 | 否 | 否 | 仅当有志愿负责人时 |
- 每次变更都构建指以 ReleaseSafe 模式交叉编译该目标，且其二进制文件通过二进制检查（允许的动态库、PE 标志、不存在可写且可执行的内存）。发布目标的
setup还必须保持在 30 MiB 的大小预算之内。 - 在真实系统上测试指在参考操作系统上运行平台契约测试套件、端到端的安装、更新、修复和卸载场景以及一次冒烟测试。对一级平台而言，已知的失败会阻塞发布；无法运行的测试在发布说明中报告为
BLOCKED或NOT_RUN，绝不报告为通过。 - 三级平台是候选平台。默认不为它们构建任何东西，也不对它们做任何承诺。
| 目标 | 层级 | 参考操作系统 | 说明 |
|---|---|---|---|
aarch64-macos |
1 | Apple 芯片上的 macOS | 最低 macOS 版本尚未确定 |
x86_64-windows |
1 | Windows 11（x64） | |
x86_64-linux |
1 | Ubuntu 24.04 LTS | 静态 musl 二进制，没有动态库依赖；其他发行版可能可用，但不在覆盖范围内 |
aarch64-linux |
2 | Ubuntu 24.04（ARM64） | 会构建并检查，用于虚拟机冒烟测试；尚不是发布目标，因此不适用大小预算 |
每个目标的结果见状态与平台。
本节只涉及平台。计划中的功能见路线图。
第一个一级平台发布之前
Section titled “第一个一级平台发布之前”每个一级平台的承诺与其测试通道之间仍有差距：
x86_64-linux： 还没有真实系统测试通道。现有的虚拟机通道在 ARM64 上运行 Ubuntu 24.04，测试的是aarch64-linux，而不是 x64 构建。x86_64-windows： 唯一的真实系统通道是在 ARM64 版 Windows 11 上以模拟方式运行 x64 构建。原生 x64 硬件不在覆盖范围内。- 所有平台： 真实系统冒烟测试只覆盖用户范围安装；整机范围安装没有在那里测试。
aarch64-macos： 在真实 Mac 上走查图形安装程序是一项尚未执行的人工检查，最低支持的 macOS 版本也有待确定。
| 候选 | 层级 | 需要什么 |
|---|---|---|
aarch64-windows |
3 | 一个构建目标和二进制检查条目，以及一条在 ARM64 版 Windows 11 上的真实系统通道 |
| 麒麟（Kylin）和统信（UOS），x86_64 和 aarch64 | 3 | 每个发行版一条真实系统通道。Linux 二进制是静态的，预期无需修改即可运行，但这未经测试；桌面集成（.desktop 条目、MIME 包、systemd 单元、XDG 目录）需要在每个发行版上检查 |
- 原生 Wayland 后端。 在 Wayland 会话中，安装程序窗口通过 XWayland 运行。该决策记录在 ADR-0010 中。
在层级之间调整
Section titled “在层级之间调整”一个平台在满足以下全部条件时升到更高层级：
- 在参考操作系统上有一条可重复、能产生记录证据的测试通道；
- 有一个明确的参考操作系统版本；
- 有一位有时间维持该通道运行的维护者。
升入一级还需要一项记录在案的决策，因为它会给每次发布增加工作。如果一个一级平台的真实系统通道连续两次发布都不可用，它会降到二级。
欢迎移植到三级候选平台，前提是有人持续维持其测试通道，且不给一级平台增加工作。这项策略本身记录在 ADR-0014 中。