跳至主内容

全新CI系统、新版仓库，全力推进10.9.0版本发布

· 1 分钟阅读
Joshua Boniface
Joshua Boniface
Project Leader
非官方测试版翻译

本页面由 PageTurner AI 翻译（测试版）。未经项目官方认可。 发现错误？ 报告问题 →

过去几周，我主导了对CI系统的重大改进工作，旨在优化发布流程、加快版本迭代速度，并减轻作为发布经理的工作负担。本文将详细介绍我们实施的改进措施，这些变化对用户和贡献者的影响，以及我们推进10.9.0版本发布周期的计划。

内容提要​

  1. 我们推出了新版仓库浏览界面，采用全新文件布局，部署在新的主仓库服务器上，由新CI系统构建。这将使浏览和查找所需内容更加便捷。该系统已投入生产环境，但仍处于完善阶段，如发现任何问题请及时反馈！请注意大量路径已变更（特别是/server目录下的内容），部分路径保持不变。若遇到404错误且无法通过界面找到文件，请及时与我们确认。第三方打包者如需手动下载文件，建议在需要时联系我们。

  2. 我们将停止提供非LTS版Ubuntu软件包，不再维护自有Fedora/CentOS软件包，转而采用RPMFusion构建版本，同时新增GHCR容器仓库作为Docker镜像源。

  3. 针对10.9.0版本，我们将不再制作专门的"beta"测试版，而是通过新版每周不稳定构建进行测试。当master分支达到足够稳定状态后，我们将直接从中发布10.9.0正式版（沿用标准发布分支流程）。

  4. 10.9.0版本的功能冻结期（此后仅接受错误修复PR）暂定于**3月18日（周一）**启动。我们希望届时所有改进均能就绪，方便获取不稳定构建进行测试。

  5. 10.9.0正式版暂定于四月最后一个周末发布。所有为我们版本制作打包的第三方，请务必阅读至文末获取关于此版本的重要说明。

下文将展开详细说明。

—— Joshua

为何重建CI系统？​

我们原有的CI系统可追溯至2019年，由几位核心成员（主要是@EraYan）基于Azure DevOps搭建。虽然相比最初使用的纯BASH构建系统是重大进步，但仍存在诸多不足：

  1. 系统逻辑理解成本较高，且依赖外部平台（Microsoft Azure）。

  2. 最终构建阶段仍依赖复杂且易出错的BASH脚本，因为...

  3. 原系统独立构建Jellyfin的服务端与网页组件，分别响应不同仓库的标签事件，最终需通过复杂机制才能合并为统一易用的软件包。

此外（虽非CI系统本身缺陷），不稳定构建长期存在更新过频问题——每次PR合并都会触发构建，虽利于快速验证功能，但对普通用户而言实际不可用。这也是我们亟待解决的问题。

当时 GitHub Actions 尚未问世，虽然我们让整套流程运转了起来，但整个 CI 系统仍然笨重且容易出错。每次大版本发布通常需要我投入 20 多个小时准备和执行，而小版本发布也至少耗时 4-6 小时。这对发布管理者而言负担巨大，而且当流程出现隐蔽故障时修复极其困难——尤其是在打上版本标签之后，因为所有 CI 逻辑都嵌在代码仓库中。

这一切导致我们的发布速度极其缓慢，从主分支测试到准备新版本发布之间从未形成清晰的工作流。

与其继续在这个框架上小修小补，大约两年前 @ferferga 和 @h1dden-da3m0n（现已离开项目）启动了迁移到 GitHub Actions 的计划。虽然他们奠定了大量基础，但该项目最终停滞并被搁置。今年初我接手这项使命，决心在 10.9.0 版本前完成迁移，并成功构建出更易理解、稳定性更高的新系统。

自动化升级​

除了 CI 本身，另一项重点是自动化机器人。如前所述，发布流程耗时漫长，但实际处理 Azure 的时间只占小部分。其余都是行政工作：编写更新日志、确保仓库同步、运行 bump-version 脚本、创建发布草稿、反复检查仍难免疏漏、撰写论坛公告等。这些琐事堆积成巨大的时间成本，让我望而却步，进而拖垮了发布效率。

任何项目都不该如此依赖单一个体，但我们长期处于这种状态。本次 CI 改进的核心目标之一，就是通过私有聊天机器人实现全流程自动化。

理想场景是：向机器人下达发布指令 → 自动生成所有文本材料 → 人工审核后确认发布。这不仅减轻我的负担，其他成员也能操作。配合更可靠的 CI 系统，有望实现"设置即忘"的发布流程，极大提升迭代速度。

虽然机器人尚未完全完工，但框架已搭建完毕，我们确信它能在 10.9.0 正式发布前投入使用。

统一软件包​

旧版 CI 的最大缺陷在于将 Jellyfin 的服务端与网页组件分开处理。这样设计是因为代码层面确实分离——它们分属不同 GitHub 仓库且由不同团队维护。但问题在于：用户实际使用的是整合产品。用户需要的是一键安装即可运行的完整包/安装程序。因此我们不得不通过复杂操作合并组件。

新版 CI 彻底改变这一状况。所有打包流程现已统一整合至专属仓库。该仓库通过子模块管理两个代码库，并用 Python 脚本同步构建所需的版本号。随后另一 Python 脚本执行实际构建任务——整个过程由 GitHub Actions 触发。虽然仍显复杂（毕竟打包多媒体软件本就繁琐），但改用 Python 实现（这门健壮且易理解的语言）后，流程透明度将远胜从前。

具体影响因打包类型而异。对于 Debian 和 Ubuntu，现在三个二进制包（元包、Web 和服务器）共享同一个 Debian 源码包，因此可以通过单条 dpkg-buildpackage 命令一次性构建全部组件。对于归档文件，服务器和 Web 组件会按顺序构建并在打包时直接合并成单一归档，取代了之前杂乱无章且故障频发的后期合并流程。对于安装程序，这意味着流程更简化且可自动化。最后对于 Docker，我们现仅提供单一镜像 jellyfin/jellyfin，该镜像采用一次性完整构建，不再依赖两个易出错的中转镜像。

与此相关的是，作为统一构建的一部分，每个 Debian 和 Ubuntu 版本现在都有专属的软件包，采用类似 -deb12 或 -ubu2204 的版本后缀。这能确保 LibSSL 等共享库的依赖处理更顺畅。此变化仅影响直接从仓库下载 .deb 包的用户：请务必下载对应您系统版本的安装包。

普通终端用户不会察觉差异：您仍可通过仓库按原有方式安装软件包。但自行构建版本的用户请注意，所有非开发用途的打包配置（如 debian/ 和 fedora/ 目录、deployment/ 目录等）将从主仓库移除，仅保留用于快速构建测试和开发镜像的简易 Dockerfile，建议使用前述专用仓库进行构建。

新 CI 系统的新主仓库​

全新设计的 CI 和统一打包使我们能够采用更清晰的仓库结构。旧结构为满足合并需求而设计，充满特殊处理和嵌套目录。摆脱这些限制后，我们实现了更合理的布局，并搭建了全新的主服务器来承载，确保平滑过渡。

同时我们还改进了浏览界面，通过更直观的树状结构让用户轻松定位所需文件。

新浏览界面和主仓库已正式上线，您可在 https://repo.jellyfin.org 上查看。为方便用户，在 10.9.0 发布前仍会以新布局提供稳定版软件包。如前言所述，欢迎测试使用，若发现链接失效或其他问题请及时反馈。

非稳定版发布​

如前所述，原先"每次合并拉取请求即构建"的模式存在明显缺陷：变更过快导致测试者难以跟进，尤其在开发高峰期。早期我们曾尝试每日构建，但即便这样对当前开发节奏和用户保持同步来说仍过于频繁。

因此我们将非稳定版发布改为每周周期。构建时间为每周一凌晨（美国东部时间午夜，UTC-5/4含夏令时），这个时间点虽稍显随意，但能确保每周伊始都有全新构建。该流程完全自动化，完成后会立即推送至所有常规渠道。

我们希望较慢的节奏既能让非稳定版用户有效测试当前状态，避免被频繁更新淹没，又能及时提供最新功能和修复供深度测试。

最后需说明（下文将详述）：这些每周非稳定版构建将直接作为 10.9.0 的预发布测试，此周期不会单独发布"beta"或"rc"版本。这能避免重蹈 10.8.0 的覆辙——既要持续向后移植稳定版的修复到主分支，又要向前移植错误修复到开发分支的繁重工作。

精简构建内容​

正如在"简要说明"部分提到的，我们将对构建内容进行三项重大调整，这些调整同时适用于不稳定版本和即将发布的10.9.0版本：

  1. 我们将从官方APT软件包仓库中移除所有非LTS的Ubuntu版本

    原因很简单：Ubuntu每6个月发布一个新版本，而我们仅仅为了支持实际上只有9个月生命周期的次要版本，负担过于沉重。尽管我们理解用户可能希望在桌面环境运行Jellyfin，或确保服务器拥有"最新"软件，但从长远来看这对我们并不可行。因此，从今往后我们的软件包将仅针对LTS版本，包括20.04 "Focal"、22.04 "Jammy"，以及将于四月发布的新版本24.04 "Noble"。

    如果您正在使用非LTS版本的Ubuntu，仍有其他选择。首先，您可以随时升级到24.04版本并使用它。但请注意，24.04将是我们构建的最后一个版本，直到26.04发布。另外，如果您仍希望保持系统处于6个月更新周期，可以转而使用我们的Docker镜像，这样即使基础操作系统变更，也能获得额外的长期稳定性。

  2. 我们将停止为Fedora和CentOS（及类似发行版）提供自有的"官方"RPM构建，转而采用RPMFusion：

    这些构建对我们而言一直有些尴尬。尽管有社区成员的英勇贡献，它们的维护状况一直不佳，经常出现问题，而当我们开始尝试整合spec文件时，问题更是集中爆发。

    幸运的是，社区成员@mooninite已经在RPMFusion上维护了一个稳定的Jellyfin整合构建。这似乎是我们切换过去的完美时机，既能减轻打包负担，又能（终于）为RPM用户提供"真正的"仓库。RPMFusion构建现已作为官方Fedora/CentOS构建列于我们的下载页面，并将持续如此。我们也在采取措施，争取在那里提供打包好的FFmpeg，敬请期待。

    Fedora/CentOS上的不稳定版本用户建议继续使用Docker容器，因为它目前已经捆绑了FFmpeg，并且有助于确保快速升级。

  3. 我们终于为Docker镜像添加了GHCR（ghcr.io）支持。这将确保即使Docker Hub发生故障，用户仍有其他镜像来源。如果您愿意，现在就可以为不稳定版本使用此来源，10.9.0版本发布后同样适用。

10.9.0版本周期​

正如我们在GitHub讨论中概述的那样，所有这些变更意味着我们将以全新方式推进10.9.0版本周期。为澄清流程，具体步骤如下：

  1. 从即刻起，所有未来版本都将以每周构建的不稳定版本（Weekly Unstable）作为"测试版"。也就是说，如果您想帮助我们测试，或只是想体验最新功能，请使用不稳定版本。您可以在下载页面找到启用不稳定版本的说明，该页面同时列出了所有支持的不稳定平台。

  2. 随着计划发布日期临近，我们将开始特性冻结（feature freeze）。冻结期间仅接受错误修复类PR。我们预计此阶段将持续3至5周。当前暂定起始日期为3月18日（星期一）。冻结期间，不稳定版本应保持稳定可用状态，仅合并少量修复。

  3. 作为用户，请务必勤于报告不稳定版本中的错误。过去几个月，我们的问题分类团队（Triage team）一直非常认真地确保问题得到分类和处理，因此使用不稳定版本的用户正确报告错误至关重要！

  4. 当我们接近稳定阶段（即经过3-5周的冻结bug修复期后），我们将决定正式发布最终版本。我个人希望在4月27日至28日的周末完成这项工作，但具体时间可能根据冻结期的进展进行调整。

  5. 正式发布流程将启动：我们将创建新的发布分支、打上版本标签，并利用前文所述的新CI系统执行发布。请特别注意：任何基于仓库标签事件触发构建的第三方 请务必在此次发布期间禁用该功能，因为我们预计在实际执行过程中至少会遇到一两个障碍。待流程稳定后，我们将确保第三方构建正常进行（以防出现需要重新打标签等重大调整）。长期来看，我们也会建立更完善的协调机制，因此诚邀第三方维护者联系我们共同优化此流程。

  6. 此后master分支将恢复正常开发，同时开启10.9.0版本的稳定修复周期。得益于这些改进措施，我们预计10.10.0版本不会间隔太久（可能在3-6个月后），届时将重新启动相同流程。

历时两年多的筹备即将开花结果！我们希望尽可能广泛地传达这项计划，尤其号召更多用户通过测试新版不稳定构建来协助我们在最终发布前发现bug。

结语​

以上就是我对10.9.0版本路线图以及发布流程改进方案的全面说明。祝大家观影愉快！