版本发布记录
最后更新: 2026-08-03
Relayium 有三种发布节奏,这一页对三种都如实说明:网页版持续部署,命令行工具带版本号打标签发布,原生应用则还是开发版,尚未公开发布。
下面每一个版本都是从 main 分支自动打标签的,而且只在该提交的检查全部通过之后才发布。某个版本的完整说明——它包含的每一条提交——在 GitHub 上一点即达。
全部已发布版本
从新到旧。每个版本都链接到 GitHub 上的完整说明与下载。
- v0.15.02026-08-03
- v0.14.02026-08-02
- v0.13.02026-08-01
- v0.12.02026-07-30
- v0.11.12026-07-28
- v0.11.02026-07-28
- v0.10.22026-07-23
- v0.10.12026-07-23
- v0.10.02026-07-23
- v0.9.02026-07-22
- v0.8.12026-07-22
- v0.8.02026-07-22
- v0.7.02026-07-13
- v0.6.02026-07-13
- v0.5.02026-07-13
- v0.4.02026-07-13
- v0.3.12026-07-13
- v0.3.02026-07-13
- v0.2.02026-07-08
- v0.1.22026-07-08
- v0.1.12026-07-08
- v0.1.02026-07-08
版本号覆盖什么
一个版本标签发布两个程序:relayium 命令行工具,以及自托管者运行的中继与存储节点 relayium-node。两者由同一份源码构建,所以只有这份源码有改动时才会切出新版本。
- 网页版没有版本号。它在检查通过后就从 main 分支部署,所以你在浏览器里用到的,通常比这里最新的版本还要新。
- macOS 与 iOS 应用是开发版,不是公开发布版。下面任何一个版本都不包含它们。
- 节点不会自己跟着这个列表走:它会向所属的服务器询问该运行哪个版本,所以在有人发起灰度更新之前,新版本什么也不会改变。命令行工具用 relayium update 更新。
一次发布是怎么切出来的
发布按排期进行,不靠谁记得。每周有一个工作流检查上个版本之后合并了什么,并在两种情况下停下、不打标签:真正会被发布的代码没有改动,以及该提交的检查没有全绿。
- 这两个停止条件都刻意如此。靠记性的结果,是一个早就写完的功能被搁置了好几个月没发布;而给一个没验证过的提交打标签,恰恰会发出排期本来要挡住的故障。
- 只改了文档或应用的那几周不会产生新版本,因为发布出来的程序会和上一版逐字节相同。
怎么校验你下载到的文件
每次发布都会在压缩包旁边附上校验和文件,以及对该文件的签名。更新程序在安装任何东西之前会用编译进程序里的公钥同时校验这两者——所以被篡改的压缩包会在你的机器上校验失败,而不是取决于我们这边有没有注意到。
- 为了访问不到 GitHub 的网络,Relayium 也镜像了自己的发布文件。字节从哪里来是可达性问题,不是信任问题:两条路径上的校验完全一样。
- 源码是公开的。服务器、节点与网页版采用 AGPL-3.0,原生应用采用 Apache-2.0,文档采用 CC BY 4.0。