发布验收与稳定性门槛
结合 CI、E2E、安装冒烟、预览使用和真实用户流程决定发布是否就绪。
This page has not been translated into English yet. The original Chinese version is shown below.
官方发布信心策略将自动检查、人工验证和运行数据结合。任一必需关卡失败，不能只凭另一项通过就提升 stable。
自动检查
| 关卡 | 官方策略列出的验证范围 |
|---|---|
| CI | nightly 的 main 或 preview/stable 的发行分支，Linux/macOS 的 lint、类型、单元测试与构建/bundle |
| E2E | Linux、macOS、Windows；Linux 至少无沙箱和 Docker |
| npm 发布后 smoke | ubuntu-latest 上确认包可安装且可执行，并返回正确版本 |
其他自动化文档对完整 CI 平台矩阵描述更广；具体运行应查看当前工作流，不能把上表当作仓库永不变化的唯一矩阵。单元测试、集成、内存/性能和行为评估的入口见开发目录。
安装冒烟命令形式为：
npx -y @google/gemini-cli@<tag> --versiontag 应换成待验收发布。返回正确版本只证明基本安装/执行，不覆盖模型、认证和工具行为。
预览与人工用户流程
官方要求 preview 至少经过维护者一周实际使用，再考虑提升 stable。发布负责人还需检查：
- 安装待验收版本并核对版本号。
- Google 登录、API key、Vertex AI 三种认证路径。
- 基础提示与交互追问是否保留上下文。
- stdin 管道输入能否被处理。
- @file 能否加入正确文件内容。
- /settings 修改是否生效。
- 工具能否创建文件且实际内容正确。
任一关键用户路径失败，应先给 preview 补丁。官方清单包含卸载与清缓存的准备示例；这些步骤会改变本地安装环境，可在专门验收环境执行，不把清空全部 npm cache 当作普通用户更新的必要条件。
高影响发布与数据
Tier 1/2 高影响发布要求至少提前 72 小时安排 bug bash。是否属于该级别由发布负责人协调，官方举例包括配套博客、媒体或集中宣传的发布。
策略还要求查看内部工具错误与离线评估仪表板。原文的内部 go/ 地址不属于公开文档，也未在本地验收中验证其内容；应由有权限的维护者完成，不用公开 CI 绿色结果代替。
提升前的决定
确认当前 preview 对应提交的 CI/E2E 通过、一周预览使用及人工路径完成、没有阻断问题，并完成遥测与模型评估检查，再触发 Promote。记录验证的是哪个版本与提交，避免拿另一个 nightly 的测试结果支持当前 stable 提升。