Forgejo 3月月报出炉，v15.0.0 定档 4 月 16 日发布。这个从 Gitea 分叉出来的代码托管平台，正在用一套"提前踩雷"的打法验证新版本——官方实例 code.forgejo.org 已经跑上了预发布分支，Mastodon 上还在喊人帮忙测试。
这不是例行更新。两个月内连发 9 个安全补丁，AI 生成代码被全面禁止，缓存远程包的功能正在社区征集需求。三件事指向同一个信号：Forgejo 团队对"可控性"的执念，已经渗透到开发流程的每个缝隙。
v15.0.0：提前 45 天"放出来挨打"
主流软件的发版节奏是"内部测完再发布"，Forgejo 选了条更累的路。v15.0.0 分支在 3 月就被切出来，官方生产环境直接当小白鼠，目的是"提前发现和修复问题"。
这种做法的代价很明显：运维团队得盯着预发布版本跑生产流量，出问题要回滚。好处也直接——用户拿到手的是被真实流量捶打过的代码，而不是实验室里的"完美版本"。
团队在 Mastodon 发了测试召集帖，呼吁用户检查常用功能和新特性是否正常。部署前的检查清单写得很硬：读发布说明、处理破坏性变更、备份数据。预发布版本已经可下载，问题往 issue 跟踪器扔，安全相关的事走安全团队渠道。
一个细节：发布说明里专门强调了"破坏性变更"。这说明 v15.0.0 里有改动会砸旧配置，不是无痛升级。对于自托管代码托管平台的用户来说，这意味着周末可能要加班。
安全补丁：两个月 9 个，外加预警机制
3 月 9 日，Forgejo 发了 v11.0.11 和 v14.0.3，配套 Helm chart 更新到 v16.2.1。这次补丁带了 7 个安全修复，4 月 10 日又追加了第 8 个安全版本。算下来从 2 月到 4 月初，安全补丁密度是平均每周 1 个。
团队抄了 Go 语言的安全发布策略：提前发预警，不透露漏洞细节，给管理员留出准备时间。想看预警的人可以订阅专用跟踪器或 RSS 源。
这个机制的设计意图很直白——承认自托管用户的安全响应能力参差不齐，用信息差帮他们争取时间。不是每个 Forgejo 实例都有专职运维，提前 48 小时知道"要出事"，足够让业余管理员设好维护窗口。
Runner 组件也在同步更新，3 月里发了 v12.7.2 和 v12.7.3，主要是 bug 修复和依赖升级。v12.7.3 加了个小功能：Runner 连接 Forgejo 实例时会用专属 User-Agent。这看起来是 telemetry（遥测）准备，方便服务端识别和统计 Runner 流量。
AI 禁令：从"兼容许可证"到"彻底禁止"
去年 Forgejo 搞了个 AI 贡献协议，允许 AI 生成代码，条件是必须兼容项目许可证。半年后，这条政策被推翻——现在全面禁止 AI 生成的工作。
导火索是协议第二条的理解混乱。这条要求"AI 生成的代码必须与 Forgejo 许可证兼容"，但贡献者搞不清什么算"兼容"。更深层的原因是"过往经验和明确的许可证顾虑"，翻译成人话：吃过亏，怕了。
这个反转的讽刺之处在于：AI 辅助编码的普及速度，超过了开源社区建立信任机制的速度。Forgejo 不是第一个对 AI 代码皱眉的项目，但把政策从"有条件允许"改成"一刀切禁止"，说明他们发现"有条件"执行起来比"禁止"还难。
所有贡献者现在必须遵守新协议。对于习惯用 Copilot 或 ChatGPT 写代码的开发者来说，这意味着提交前得人工审查每一行，确保没有 AI 痕迹。审查成本转嫁给了贡献者。
OCI 缓存：一个还没开始做的功能，先问用户要不要
2 月开的讨论帖，关于缓存远程包，特别是 OCI 包（Docker 用的那种）。现在 3 月结束，状态还是"征集反馈中"。
团队的顾虑写得很清楚：怕做出来没人用，或者用起来不对。所以功能开发被按住，先确认需求真实存在。这种"需求验证前置"的做法，和产品经理做用户访谈再排优先级是一个逻辑。
但这也暴露了一个尴尬：Forgejo 社区对容器化工作流的覆盖度，可能没想象中高。如果是 GitHub 或 GitLab，OCI 缓存的需求不需要讨论，用户会用脚投票。Forgejo 得先问，说明其用户画像更偏向传统代码托管，容器场景可能是增量而非基本盘。
讨论帖还在开放，需要这个功能的人可以去留言。目前看来，这个功能会不会进路线图，取决于有多少人愿意花时间写用例。
Forgejo 的 3 月像是一个开源项目的"中年体检"：安全债务在还，技术债务在控，新功能不敢乱上，AI 这种外部变量直接拒掉。4 月 16 日的 v15.0.0 是个节点，但更值得看的是发布后的 issue 列表——那些"提前发现和修复"的问题，有多少是真的被干掉了，又有多少只是被推迟了？
热门跟贴