Relayium

版本发布记录

最后更新: 2026-10-22

Relayium 有四种发布节奏，这一页对四种都如实说明：网页版持续部署，命令行工具带版本号打标签发布，macOS 应用单独发布——macOS 1.5.0 已可从 GitHub 下载，同时也在 Mac App Store 上架，版本号自成一条线——Android 应用则以 APK 直接分发的预览版形式，用 android-v0.3.3 标签发布。

现在，新版本由维护者从 main 分支手动打标签，而且只在该提交的检查全部通过之后才打。某个版本的完整说明——它包含的每一条提交——在 GitHub 上一点即达。

全部已发布版本

从新到旧。每个版本都链接到 GitHub 上的完整说明与下载。

版本号覆盖什么

一个版本标签发布两个程序：relayium 命令行工具，以及自托管者运行的中继与存储节点 relayium-node。两者由同一份源码构建，所以只有这份源码有改动时才会切出新版本。

  • 网页版没有版本号。上线的是经过验证后被选定投产的提交，与下面的版本标签相互独立，所以你在浏览器里用到的并不对应这里的任何一行，通常也比最新的一行更新。
  • macOS 应用用自己的标签 macos-v1.5.0 单独发布：这是一份经过 Developer ID 签名、通过 Apple 公证、直接从 GitHub 下载的安装包。独立维护版本号的 Mac App Store 版本当前为 1.4.10。下面任何一个版本都不包含这个应用。
  • 节点不会自己跟着这个列表走：它会向所属的服务器询问该运行哪个版本，所以在有人发起灰度更新之前，新版本什么也不会改变。命令行工具用 relayium update 更新。
  • Android 应用用自己的标签 android-v0.3.3 单独发布：以 APK 直接分发，不在 Google Play 上架。它是公开预览版，版本号与本页其他内容互相独立，下面任何一个版本都不包含它。

一次发布是怎么切出来的

维护者通过给 main 分支上的一个提交打标签来切出发布，而且只在真正会被发布的代码——命令行工具或节点——自上个版本以来有改动、并且该提交上的每一项检查都已通过时才这样做。打标签之后会构建并发布压缩包、校验和文件及其签名，GitHub 上的发布页会注明它的源提交，并列出自上个版本以来的每一条提交。

  • 检查必须先通过，因为给一个没验证过的提交打标签，恰恰会发出这些检查本来要挡住的故障。
  • 只改了文档或应用的改动不会产生新版本，因为发布出来的程序会和上一版逐字节相同。

怎么校验你下载到的文件

每次命令行发布都会在压缩包旁边附上校验和文件，以及对该文件的签名。relayium update 在安装任何东西之前会用编译进程序里的公钥同时校验这两者——所以被篡改的压缩包会在你的机器上校验失败，而不是取决于我们这边有没有注意到。

  • 为了访问不到 GitHub 的网络，Relayium 也镜像了自己的发布文件。字节从哪里来是可达性问题，不是信任问题：两条路径上的校验完全一样。
  • Android 的机制不一样，本页不会含糊其辞：应用只在你主动点击时才检查新版本，然后把下载页面交给浏览器打开——它自己既不下载也不安装，因此无法校验它指向的那个文件。真正保护安装的是 Android 自身的规则：更新必须与被替换的应用带有相同的签名证书。APK 旁边会公布 SHA-256，你想手动核对时可以用。
  • 源码是公开的。服务器、节点与网页版采用 AGPL-3.0，原生应用采用 Apache-2.0，文档采用 CC BY 4.0。