Zed 编辑器 v1.25.1-pre 发布：一次小版本更新释放的信号

Zed 在 GitHub 上打出了 v1.25.1-pre 标签。这条 commit 由 zed-zippy 于 10 月 20 日 09:27 标记，提交说明只有一行："Bump to 1.25.1 for @bennetbo"。没有 changelog、没有 release note、没有功能列表——但正是这种「信息极简」的发布方式，透露出 Zed 当前的版本节奏与团队协作模式。

v1.25.1-pre 到底发布了什么

从可获取的信息来看，v1.25.1-pre 是一个 pre-release（预发布）标签，对应 commit 305afe0，该 commit 通过 GitHub 的 verified signature 签名，GPG key ID 为 B5690EEEBB952194，说明提交来源可验证、未被篡改。

提交信息中的 "Bump" 通常指版本号自增，属于发布流程中的机械性操作；"for @bennetbo" 则表明这次版本推进主要是为某位具体贡献者（GitHub 用户 bennetbo）的工作服务。换句话说，这不是一个面向用户的功能版本，而更像是为某条开发线准备的版本基线。

Zed 采用 pre 标签先行、稳定版后至的节奏，社区和下游打包者可以提前验证，普通用户则等正式版即可。

pre-release 标签与 SemVer 预发布标识：在语义化版本（SemVer）规范中，1.25.1-pre 里的 -pre 属于「预发布标识符」（pre-release identifier），其排序低于同版本的正式版 1.25.1。这意味着包管理器（如 npm、Cargo）默认不会把预发布版本纳入常规升级范围，只有显式指定才会拉取。Zed 用这种命名而非 1.25.1-alpha.1，说明它只区分「预发布」与「稳定」两档，没有细粒度的测试阶段划分，与其「pre 先行、stable 后至」的双轨节奏一致。

GitHub Release 与 git tag 的区别：git tag 只是指向某个 commit 的指针，而 GitHub Release 是在 tag 之上附加发布说明、资产文件和订阅通知的封装层。Zed 选择走 Release 机制，使版本变化可被 Release API、RSS 与自动化工具感知，这是它比单纯打 tag 更利于下游集成的关键。

为什么一个 "Bump" 提交也值得关注

对多数项目而言，版本号 bump 是最不值得写文章的一类提交。但放在 Zed 身上，它至少说明三件事。

第一，发布流程已经高度自动化。 标签、签名、资产上传都按固定流水线完成，人只需要触发。这种「无惊喜」的发布恰恰是工程成熟的标志。

第二，维护者与贡献者之间的协作颗粒度很细。 版本推进精确归属到个人，说明团队在用 PR 级别的粒度管理发布内容，而不是攒一个大版本再统一发。

第三，pre 渠道持续存在。 对把 Zed 当作日常主力编辑器的开发者来说，pre 标签意味着可以更早拿到修复；对插件作者和下游发行版来说，它是兼容性验证的窗口。

从发布页细节看 Zed 的工程规范

发布页面本身透露了不少工程习惯。commit 带有 GitHub verified 标记，使用 GPG 签名，并开启了 vigilant mode——这意味着签名校验是强制性的，而非常规提醒。

资产（Assets）区域列出 2 个文件，但页面加载时出现错误提示，无法确认具体内容。页面上还出现了 "Compare"、"Choose a tag to compare" 以及多次 "Sorry, something went wrong" 的加载失败提示，这属于 GitHub 页面动态加载的常见问题，不代表仓库本身异常。

一个值得留意的细节是：Zed 选择在 GitHub 原生 release 机制里发布 pre 版本，而不是仅靠 git tag。这让订阅 release 的用户和自动化工具都能第一时间感知版本变化。

GPG 签名与 vigilant mode：GitHub 的 vigilant mode（警戒模式）是一项账户级设置，开启后所有 commit 都会被标记签名状态——未签名的 commit 显示为「Unverified」，而不是静默通过。配合 GPG 签名，维护者可以证明某次提交确实出自持有私钥的人，防止仓库被冒名推送。文中提到的 key ID B5690EEEBB952194 即签名公钥的短标识，可用于在密钥服务器上反查签名者身份。

verified signature 的验证链条：GitHub 校验 commit 签名时，会将 commit 中的签名与提交者账户绑定的公钥比对，二者匹配才显示 Verified。这条链保证的是「提交来自该账户」，而非「代码内容正确」，因此它是供应链安全的必要非充分条件。

开发者应该怎么用这个版本

对普通用户，结论很直接：如果不是刻意追新，等待 stable 版本更稳妥。pre 版本没有配套说明，意味着变更范围未公开，遇到问题时排查成本较高。

对插件开发者与下游维护者，v1.25.1-pre 是提前跑一遍兼容性测试的好机会。可以关注编辑器 API、LSP 行为、扩展加载机制是否出现回归，并在正式版发布前反馈问题。

对关注 Zed 演进方向的人，这类提交本身信息量有限，但把它和后续 stable release 的 changelog 对照，能看出哪些改动是在小版本里悄悄修掉的——这往往比大版本公告更能反映项目的真实重心。

最后需要说明：本次发布未提供任何功能描述或修复清单，因此本文不对 v1.25.1 的具体改动做任何推测。所有判断均基于发布页可见的元数据（标签、commit 签名、提交说明、提交者）以及 Zed 一贯的发布习惯。

常见问题

v1.25.1-pre 是正式版吗？ 不是，pre 是预发布标签，面向早期验证者。

这个版本改了什么？ 官方未公布变更内容，提交说明仅提到版本号推进。

普通用户该升级吗？ 建议等待 stable 版本；需要尝鲜或做兼容性测试的开发者可以先行试用。