摘要

本提案旨在改进 PCL CE 版本发布机制，以便使本体更新机制更加清晰并提升用户的更新体验。

历史

• 2025-11-09：初稿创建，由 Pigeon0v0 编写。
• 2026-01-16：提案变更为已提交状态。

目标

• 修改关于本体更新通道的描述与定位；
• 允许用户更灵活地选择本体更新策略；
• 将不同更新通道的版本更新分离，而不是使用单线模型。

非目标

• 不变更文件分发形式。

成功指标

• 用户针对本体更新机制的提问与反馈减少。

动机

随着 Nightly（暂名）更新通道即将推出，现有本体更新机制将更加复杂，用户可能难以理解各个通道的区别。

同时，此前一直采用的单线模型也有不少弊端：

• 正式版发布会阻塞测试版的开发流程，因为需要提前进行稳定性测试与准备；
• 若在最新正式版发布后发布了测试版，将导致开发者不能针对正式版推出小型更新而不包含尚不满足正式版交付要求的功能；
• 无法将一些大型功能较早交付给测试版用户测试，而必须提前进行独立的构建、分发与测试，增加了人力成本。

对于本体更新的用户体验，存在以下问题：

• 选择 在有新版本时显示提示 选项时，部分用户希望尽可能缩短 显示提示 - 点击更新 - 更新完成 流程的用时，而互联网连接速度可能不稳定，导致下载用时较长，给使用带来了不确定性。

描述

本提案提议将 PCL CE 本体更新分为以下几种通道：

• Release（正式版）
  基本稳定的版本，仅推送修复性更新与部分内置资源更新，适合大多数用户使用。
  此通道的版本号规则：M.X.Y 其中 M 为主要版本号，一般固定为 2；X 为次要版本号，一般单调递增，且对每个正式版分支唯一；Y 为补丁版本号，一般单调递增，且针对每个正式版分支独立计算。
• Beta（测试版）
  可能不稳定的测试版本，将会进行功能的早期测试，适合希望帮助测试且有一定技术能力的用户使用。
  此通道的版本号规则：M.X.Y-beta.Z 其中 M 为主要版本号，一般固定为 2；X 为次要版本号，一般单调递增，且比最新正式版分支大 1；Y 为补丁版本号，固定为 0；Z 为 Beta 构建号，一般单调递增。
• Dev（开发版）
  可能极不稳定的开发版本，直接从最新源代码构建，适合高度技术性用户。
  此通道的版本号规则：M.X.Y-dev.<commit hash> 其中 M.X.Y 规则与 Beta（测试版）一致，<commit hash> 为当前构建对应的 Commit Hash（取前 7 位）。

在开发过程中，开发者应当在正式版更新时迁出 release/M.X 分支，然后针对该分支发布 Release。针对正式版分支的补丁移植，相关 PR 应当在标题末尾附上 release/M.X 标记，并添加 backport 标签。

对于本体更新选项：

• 将 在有新版本时显示提示 选项分离为 自动下载并提示更新 与 提示更新
  选择 自动下载并提示更新 时，启动器先行检查更新并下载可用更新，在下载完成后提示用户更新，用户确认后开始安装流程；选择 提示更新 时，启动器检查更新，并在有可用更新时提示用户更新，用户确认后再开始下载
• 将 在有新版本时自动下载 选项修改为 自动下载并安装更新，并提供相关说明，提示用户该选项在更新前无显著提醒。

影响

将涉及软件内界面文本修改、功能调整、开发流程变更。

兼容性

支持从较早版本升级到使用新发布机制的版本。

替代方案

曾考虑直接在现有 Slow Ring / Fast Ring 通道模型上修改，但可能造成用户困惑。