非官方测试版翻译

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

版本发布流程

本文档为核心团队提供指导，同时公开分享以确保发布流程的透明度。

版本号规则

Jellyfin 采用语义化版本。所有版本号均为 X.Y.Z 格式，从 10.0.0 开始。请注意，10.Y.Z 版本序列代表代码库的"清理"工作，因此应理解 10.Y.Z 会在某个时间点破坏与之前 Emby 兼容接口的兼容性，并且如果后续清理工作需要，也可能破坏与之前 10.Y 版本的兼容性。我们的版本号规则通常遵循以下模式：

X: 主版本

破坏与 HTTP 或插件 API 的兼容性

Y: 次版本

引入新功能
进行向后兼容的次要 API 变更

Z: 热修复版本

关键错误修复或次要变更

通用发布理念

版本发布通常在周日"准备就绪时"进行。对于主/次版本，"准备就绪时"通常相当灵活，即版本真正就绪且没有重大破坏性错误时。主版本发布后，每个周日管理员团队应审查最近合并的 PR，如果需要回迁，则执行包含这些 PR 的热修复版本发布。

主版本发布流程

准备阶段

通过 master 分支的每日构建持续进行测试，因此继续之前 master 应基本无问题。master 的版本号应已反映即将发布的主版本号（例如 X.Y.0）
当 master 在大量工作后处于基本稳定状态时，通过 jellyfin-dev Matrix/Riot 频道和论坛宣布即将发布"黄金每日构建"
收集测试信息，并根据需要重复此过程
当版本被认为稳定且可工作时，通过 jellyfin-dev Matrix/Riot 频道宣布完全 PR 冻结
允许再发布一次"黄金每日构建"并至少进行 48 小时的测试。如果发现重大破坏性错误，则重新启动此流程
所有测试完成且版本保持稳定后，继续后续步骤

发布 Web 客户端

在 jellyfin-web 仓库中通过 CLI 从 master 创建发布分支，命名为 release-X.Y.z（其中 X 和 Y 为新版本号，z 为字面量 z）。将新分支推送到 GitHub
为新版本创建 GitHub 发布，基于新创建的 release-X.Y.z 分支。标签应命名为 vX.Y.Z（例如 vX.Y.0），发布命名为"Release X.Y.Z"。发布正文应仅包含以下链接，并根据需要替换版本号：
```
[Please see the release announcement on the main repository.](https://github.com/jellyfin/jellyfin/releases/tag/vX.Y.Z)
```
发布此版本

发布服务器

在 jellyfin 仓库中通过 CLI 从 master 创建发布分支，命名为 release-X.Y.z（其中 X 和 Y 为新版本号，z 为字面量 z）。将新分支推送到 GitHub
为这个新版本创建 GitHub 发布，基于刚创建的 release-X.Y.z 分支。标签应命名为 vX.Y.Z（例如 vX.Y.0），发布标题为 "Release X.Y.Z"。发布正文应包含以下组成部分：

a. 在 # Jellyfin X.Y.Z 标题下添加简短导语

b. 在 ## New Features and Major Improvements 标题下列出功能清单（如可用请附带 Fider 内联链接）

c. 在 ## Important Release Notes 标题下按平台分类列出已知发布说明（如 [All] 或 [Windows]）

d. 如适用，在 ## FFmpeg 标题下添加 FFmpeg 相关说明或注释

e. 在 ## Changelog 标题下提供完整更新日志，按仓库分组并添加 ### [repo](https://github.com/jellyfin/repo) 子标题。每个条目应包含 PR 编号及其标题
发布此版本
等待构建完成
在 jellyfin-announce Matrix/Riot 频道和论坛发布新版本公告

热修复发布流程

在 master 分支日常开发过程中，通过给 PR 添加 stable-backport 标签筛选适合向后移植的 PR。所有 PR 都以 master 为目标分支，因此针对稳定版的错误修复必须包含此标签才能被纳入
从所有相关仓库收集已合并的带 stable-backport 标签的 PR 列表
对每个仓库执行稳定分支的 PR 协调：
1. 对每个待移植的 PR：
  1. 从 master 分支获取该 PR 的合并提交哈希值
  2. 通过命令将合并提交移植到 release-x.y.z 分支：git cherry-pick -sx -m1 <merge-commit-hash>
  3. 解决所有合并冲突（通常保留合并提交的内容）。若存在严重冲突，通常表明该修复不适合向后移植
  4. 通过 git add 和 git commit -v 完成移植提交
2. 对主仓库 jellyfin，使用 bump_version 脚本将版本号更新至新热修复版本，提交变更并附注 "Bump version for X.Y.Z"
3. 将更新后的发布分支推送到 GitHub

Web 客户端

基于相应的 release-X.Y.z 分支创建 GitHub 发布。标签应命名为 vX.Y.Z，发布标题为 "Release X.Y.Z"。发布正文只需包含以下链接（请替换实际版本号）：
```
[Please see the release announcement on the main repository.](https://github.com/jellyfin/jellyfin/releases/tag/vX.Y.Z)
```
在 GitHub 和归档仓库发布此版本

服务端

为这个新版本创建 GitHub 发布，基于相关的 release-X.Y.z 分支。标签应命名为 vX.Y.Z，发布名称应为 "Release X.Y.Z"。发布正文需包含以下组成部分：

a. 在 # Jellyfin X.Y.Z 标题下添加简要概述

b. 在 ## Important Release Notes 标题下列出重要的发布说明，按相关平台分类（例如 [All] 或 [Windows]）

c. 如果适用，在 ## FFmpeg 标题下添加 FFmpeg 相关的发布说明/评论

d. 在 ## Changelog 标题下提供完整的变更日志，按仓库拆分并添加 ### [repo](https://github.com/jellyfin/repo) 子标题。每个条目应包含 PR 编号和 PR 标题
发布该版本
等待构建完成
在 jellyfin-announce 频道及其他必要渠道发布新版本公告

版本号规则​

X: 主版本​

Y: 次版本​

Z: 热修复版本​

通用发布理念​

主版本发布流程​

准备阶段​

发布 Web 客户端​

发布服务器​

热修复发布流程​

Web 客户端​

服务端​