10.6.0 版本的打包更新
本页面由 PageTurner AI 翻译（测试版）。 未经项目官方认可。 发现错误？ 报告问题 →
长久以来，版本发布和测试用二进制文件的打包构建一直是我们面临的挑战。从修补临时拼凑的脚本到测试破坏性变更，再到精心调整正式版本，过去一年半的打包流程亟需改进。
值得庆幸的是，这些改进现已全部完成。本文将详细介绍相关变更及其对用户的影响。
简要总结：对于使用稳定版的大多数用户而言，升级到 10.6.0 的方式与以往相同，基本不会感受到变化。若您正在使用每夜构建版进行测试、拥有高级配置环境，或单纯对此感兴趣——请继续阅读！
拆分式构建
本次打包变更的核心是拆分式构建。此前我们通过非常规手段将 Web UI（https://github.com/jellyfin/jellyfin-web）和服务器端（https://github.com/jellyfin/jellyfin）合并为单一安装包。随着两个代码库更新量激增、迭代速度加快，加之我们最终需要实现两者的发行版解耦，原有方案已达极限。这点在构建 10.5.4 和 10.5.5 版本时所需的幕后工作中体现得尤为明显。
采用拆分打包后，两个代码库现已实现全平台独立构建。构建 jellyfin-web 代码库将生成仅包含 Web UI 的 Docker 镜像、.deb 包、.rpm 包或 .tar.gz 压缩包；而构建 jellyfin 代码库则输出您熟悉的各种 Docker 镜像、.deb、.rpm、.tar.gz 及 .zip 归档文件。
主要区别在于命名规范：jellyfin-web 代码库的二进制文件命名为 jellyfin-web，而 jellyfin 代码库的则命名为 jellyfin-server。以 Debian 系统为例，原先的 jellyfin 软件包现已拆分为 jellyfin-web 和 jellyfin-server。但请放心，jellyfin 并未消失——我们稍后会详细说明。
Azure Pipelines 构建
我们之前的构建基础设施堪称"意大利面式"系统——在 DigitalOcean 云服务器上运行的 Bash、Python 和 Docker 脚本交织缠绕。这套系统虽然基本可用，但流程极其脆弱且不透明（甚至我这个编写者也不完全清楚其运作原理！），同时消耗大量资源。
随着测试、验证、代码检查等功能逐步迁移至 Azure，我们发现 Azure Pipelines 具备高度灵活性，几乎能完成所有构建步骤。这至少节省了三分之二的构建服务器资源，还带来了新特性——我们稍后会提及的不稳定构建功能。
Azure Pipelines 构建任务负责处理前文所述两个代码库的所有归档文件生成，将二进制制品上传至构建服务器后，仅需触发单个脚本即可完成剩余三分之一流程。整个过程更加清晰透明，所有参与者都能在 Azure 项目页面查看构建结果。
元包与元镜像
前文提到，原先名为 jellyfin 的软件包现已更名为 jellyfin-server，且不再包含 Web 界面。那么如何获取完整功能？升级如何实现无缝过渡？答案就在于元数据包（metapackages）、元归档文件（metaarchives）和元镜像（metaimages）！这些新组件可在此仓库页面查看，其中 Docker 镜像将作为这些配置的权威来源。下面我将简述各平台的具体实现方式。
对于 Docker 平台，Azure Pipelines 的分割构建会生成名为 jellyfin/jellyfin-server 和 jellyfin/jellyfin-web 的 Docker 镜像。它们本身功能有限，主要服务于后续流程。当 Azure 构建完成并上传这些镜像后，构建服务器会触发脚本创建 jellyfin/jellyfin "元镜像"——该镜像将两个独立镜像与运行所需组件（如 jellyfin-ffmpeg）合并为单一 Docker 镜像后推送。最终产物仍是用户熟悉的 jellyfin/jellyfin 镜像，但构建过程改为独立完成，不再依赖构建步骤中的 git clone/归档下载等操作。
在 Debian 和 Ubuntu 系统中，Azure Pipelines 的分割构建会为每个组件生成独立可用的 .deb 包。用户可直接通过 apt install jellyfin-server jellyfin-web 安装 Jellyfin 10.6.0+ 版本。元数据包是一个独立的 .deb 包，名为 jellyfin，其唯一功能是声明对这两个组件的依赖关系。因此安装 jellyfin 时将自动获取 jellyfin-server 和 jellyfin-web 及其依赖项，这正是无缝升级的关键：从旧版 jellyfin 升级到新版 jellyfin 时，系统会自动 引入新子包并移除旧包，全程无中断。
Fedora 和 CentOS 的实现与 Debian/Ubuntu 类似，主要区别在于元数据包属于 jellyfin-server 仓库组件，仅在该仓库更新时重建。由于我们未像 Debian/Ubuntu 那样提供"正式"仓库，因此影响有限，对稳定版用户则完全无感。
Windows 安装程序和 macOS .app 软件包的构建流程仍稍显复杂且处于开发阶段（WIP），但正式发布时均可正常使用。
其他平台（包括 Windows/macOS/Linux 归档包及 .NET 便携版）会将构建生成的独立 .tar.gz/.zip 归档合并为同类型 jellyfin 归档包，组件文件将置于对应位置。与前述方案相同，用户下载"合并版"归档包即可无感体验变更。
非稳定版构建
新架构的重要优势在于支持"非稳定版"构建。此前我们提供的"每夜版"（nightly）存在明显缺陷：频繁中断构建；单日可能包含十余个 PR 变更；组件版本常出现混乱（如未分割构建可能抓取错误 Web 版本）。
全新的拆分构建、Azure 构建以及元包/元镜像方案实现了质的飞跃：现在能为_每个合并的 PR_ 构建"不稳定"版本。我们无需再担忧资源占用（Azure 提供支持）、磁盘空间或构建流程的其他环节。问题发生时能即时发现，更重要的是，它让测试人员能清晰追溯所用代码库版本及最后合并的 PR，实现 master 分支的透明化测试。
不稳定版本的构建基于 Azure 构建 ID 进行版本控制，其格式为"[日期].[ID]"，例如 "20200620.12" 表示 2020 年 6 月 20 日的第 12 次构 建。该版本字符串可精确追溯二进制文件的生成来源及触发构建的 PR。对于包含变更日志的二进制文件（目前仅限 .deb 和 .rpm 包），变更日志数据也会明确包含 PR ID。
如何使用不稳定版本
使用不稳定版本与之前的 nightly 版本略有不同。此前 nightly 包/镜像命名为 jellyfin-nightly 或 Docker 的 jellyfin:nightly，并存储在同一仓库中。现在命名方式有所调整，下文将分平台说明具体变更。请注意，在 10.6.0 正式发布前，我们将继续按原有方式构建 nightly 镜像，之后将完全转向 unstable 构建。如果您习惯使用最前沿版本，请详细阅读本节内容并尽快完成相应配置调整。
对于 Docker 用户，新的不稳定版本可通过 unstable 标签获取，例如 jellyfin/jellyfin:unstable，或使用带具体版本的标签如 jellyfin/jellyfin:20200620.12-unstable。跟随主 unstable 标签可始终获取最新构建，而带版本号的标签便于测试或调试特定构建。
对于 Debian 和 Ubuntu，unstable 镜像的存储位置已变更。如前所述，此前它们位于仓库的 main 区域并使用别名 jellyfin-nightly，而现在对于 unstable 情况已不再如此。相反，我们创建了一个名为 unstable 的独立仓库分区来存放 unstable 版本，且不再重命名。要启用此额外组件，请在 /etc/apt/sources.list.d/jellyfin.list 中添加如下配置行（仅需将 main 替换为 unstable）：deb [arch=amd64] https://repo.jellyfin.org/debian buster unstable。由于版本控制机制，启用该源后系统将始终优先安装版本号"极高"的 unstable 包。如需禁用，请删除此行后执行 apt update，移除旧包再安装稳定版本。
对于其他版本用户，由于始终需从仓库站点手动下载文件，变更不大——只需从对应平台的 nightly/ 目录改为 unstable/ 目录下载即可。请注意，分离构建机制使这些目录包含 server、web 和 combined 子目录；通常您应选择 combined 压缩包，使用方法与之前完全一致。
结语
感谢您阅读本次构建变更说明。我们将持续进行全面测试以修复问题，如有疑问或建议，欢迎通过 Matrix 联系我们！
期待很快为您带来 10.6.0 版本及更多采用新构建格式的后续发布！