Gitea 28.0.0发布：版本号去掉1前缀，升级前先确认Actions历史保留

10-01 4阅读

Gitea于2026年9月30日发布28.0.0，明确移除历史版本号中的“1.”前缀。此版新增审计等能力，但审计日志默认关闭；已完成Actions运行默认在400天后连同任务、日志和产物一起清理。公告还列出网络出口和工作流等重大变更，因此升级不应只核对版本名称。

AI生成概念示意图，非真实产品照片或软件界面。

先找出哪些历史记录仍在被使用

本文认为，这次升级最应提前处理的是保留需求。许多团队以为旧构建只是临时记录，却会在排查回归、重新交付或解释某次发布时回头寻找它们。是否需要继续保留，应由实际用途决定，而不能由“很久没有点开”来判断。

可以从最近一次发布向后追问：交付物从哪次构建而来，当时用了什么配置，相关说明是否只存在于运行日志里。若关键证据只有一份，就需要先确定它的保存方式，再安排升级窗口。

配置保留时间时，也要明确谁负责定期复查。无限保留并不天然适合所有团队，过短保留也可能让排障缺少依据。更有用的做法是把记录分成仍服务于具体工作和可按约定清理两类，并让参与者知道在哪里找。

一个小型测试实例可以承接现有配置的副本，再用专门仓库走一次日常流程：获取代码、提交修改、触发构建、查看输出和下载产物。每一步都应由平时使用该功能的人确认，而不只是管理员观察服务能够启动。

对于自动化脚本，还应检查它们如何选择下载文件和识别版本。脚本若只接受旧格式的版本字符串，可能在服务器升级前就停止工作。测试时保留原始输出与错误信息，便于区分下载脚本问题和服务本身的问题。

网络相关验证可以从一条已获允许的测试连接开始，并检查不需要的目标仍无法访问。具体设置应依据官方迁移说明逐项确认，不能把原配置原样复制过去就推定含义未变。这里是升级验收建议，不是替代完整配置文档。

如果团队选择使用审计能力，可以设计一次普通操作并查找对应记录，再让另一位维护者根据记录解释发生了什么。能够产生记录与记录足以支撑交接，是两个需要分别验证的问题。

升级完成的标志，应是日常工作链能够继续、历史材料能按约定找到、维护者知道怎样处理异常。保留一次测试结果和恢复步骤，会让下次更新更容易安排，也让版本变化不再只是一次替换程序文件的操作。

本文于北京时间2026年10月1日核验。新闻事实来自上述第一手资料；场景推演与评估建议为本站独立分析，功能范围以官方后续说明为准。