Windows Terminal 2022 路线图详解6 周里程碑、双渠道发布与问题分级机制【免费下载链接】terminalThe new Windows Terminal and the original Windows console host, all in the same place!项目地址: https://gitcode.com/GitHub_Trending/term/terminal本文以仓库内的 doc/roadmap-2022.md 为主体完整梳理 Windows Terminal 2022 年度路线图的规划模型6 周里程碑节奏、Preview 与 Stable 双渠道交付、按学期22H1/22H2组织的里程碑划分以及 P0~P3 的 Issue 分级规则并结合仓库中的特性分级配置与发布工程脚本说明这套先 Preview、后 Stable的承诺在源码层面是如何落地的帮助读者既看懂路线图本身也理解其背后的工程机制。文档定位一份已被接替但仍具参考价值的规划文档doc/roadmap-2022.md 的开头带有明确的注记该文档已被 Terminal 2023 Roadmap 取代最新的规划应以后者为准。它本身是 Terminal v2 Roadmap 的继任文档反映的是团队规划方式的转变。2022 路线图 Overview 部分交代了两个关键决策这是理解整份文档的前提放弃Terminal v2这一刚性目标。团队最初计划过一个独立的 Terminal v2 里程碑但在随后约 18 个月的工作中发现不需要一个严格的 2.0 版本持续、渐进的更新已经能有效服务社区。原文写道若未来某个发布值得 2.0 之名届时再重新评估。改用学期semester里程碑跟踪全年工作。2022 年采用22H1与22H2两个学期里程碑大致对齐 Windows 内部截止日期。文档解释了原因虽然 Windows Terminal 的更新独立于操作系统发布out-of-band但团队仍背负着修复更大控制台生态中 Bug 的承诺这些修改必须与操作系统其余部分同步完成。将外部里程碑与这些内部截止日期对齐有助于保证 Bug 被及时修复并合入 OS。此外这两个学期里程碑还继承了原 Terminal v2 里程碑的剩余工作随着 22H1/22H2 中的特性与 Bug 被逐步消耗团队会从Up Next里程碑中拉入新特性而Up Next本身则由最高优先级的 Backlog 条目填充。文档中22H1、22H2、Up Next、Backlog原本均链接到项目仓库的对应 GitHub Milestone这些是文档写作时2022 年中的快照现在应视为历史规划状态。里程碑模型6 周一轮Preview 先行、Stable 滞后一个月Milestones 一节定义了 Windows Terminal 的工程与交付模型原文表述为Windows Terminal is engineered and delivered as a set of 6-week milestones. New features will go into Windows Terminal Preview first, then a month after theyve been in Preview, those features will move into Windows Terminal (stable). These timelines are rough estimates, not strict rules.拆解为三条规则6 周一个里程碑工程以 6 周为周期推进每个周期产出可发布的构建新功能先进 Preview所有新特性首先出现在 Windows Terminal Preview 通道约一个月后进入 Stable特性在 Preview 中稳定约一个月后随下一个 Stable 发布进入 Windows Terminal 稳定渠道。文档同时强调这些时间线是粗略估计而非硬性规定。这套双渠道滞后一个月的机制与后文 2023 路线图描述的四品牌渠道Release / Preview / Canary / Dev共同构成了该项目的发布体系。2022 年发布排期表原文包含一张完整的里程碑时间表列出各里程碑进入 Preview 与 Stable 构建的日期。以下为完整继承的表格原表中每行还关联了当期的 Preview 发布博客链接此处略去外部链接里程碑截止日里程碑内容2020-06-181.1 进入 Preview2020-07-311.2 进入 Preview1.1 进入 Stable2020-08-311.3 进入 Preview1.2 进入 Stable2020-09-301.4 进入 Preview1.3 进入 Stable2020-11-301.5 进入 Preview1.4 进入 Stable2021-01-311.6 进入 Preview1.5 进入 Stable2021-03-011.7 进入 Preview1.6 进入 Stable2021-04-141.8 进入 Preview1.7 进入 Stable2021-05-311.9 进入 Preview1.8 进入 Stable2021-07-141.10 进入 Preview1.9 进入 Stable2021-08-311.11 进入 Preview1.10 进入 Stable2021-10-201.12 进入 Preview1.11 进入 Stable2022-02-031.13 进入 Preview1.12 进入 Stable2022-05-241.14 进入 Preview1.13 进入 Stable未定1.15 进入 Preview1.14 进入 Stable未定1.16 进入 Preview1.15 进入 Stable未定1.17 进入 Preview1.16 进入 Stable从表中可以读出三个事实排期实际跨度从 2020 年 6 月开始说明该表是滚动维护的2022 年路线图只是在其中续写了后续行1.13 与 1.14 之间出现了明显的空档2022-02-03 到 2022-05-24且 1.15 及之后没有日期原文特意强调日期是粗略估计可能变化版本号采用Major.Minor的两位递增1.1 → 1.17与后文发布脚本中解析VersionMoniker Major.Minor的做法一致。2022 年下半年发布草案Gantt 视图原文还附有一段极其模糊的下半年排期草案明确说明它起草于 2022 年 5 月末、仅供内部规划参考、不代表官方日期发布更常与官方特性的落地同步而不是与某个任意日期同步并预期会偏离初稿。该草案以 Mermaid 甘特图给出 1.14 ~ 1.18 的节奏甘特图暴露出 2022 年版本的单个发布周期结构Features约 4 周的特性开发窗口Bugfix1~2 周的缺陷修复窗口Lock down bake约 1~2 周的锁定与烘焙期不再引入新工作只做稳定化Release / becomes StablePreview 发布后该版本在下一个周期的末尾进入 Stable 渠道——这正是Preview 先行、约一个月后进入 Stable规则在时间轴上的具体形态。值得注意1.15 在 1.14 发布后紧接着才进入 Features 阶段而 1.15 发布后还有1.15 becomes Stable的里程碑点与上一节表格中1.15 进入 Preview 时 1.14 进入 Stable的双线推进完全对应。Issue 分诊与优先级规则原文最后一节Issue Triage Prioritization描述了问题进入路线图前的分诊流程新提交的 Issue/请求每周数次被分诊、打标签并按优先级顺序分配到里程碑。完整规则如下P0严重崩溃、数据丢失等尽快处理直接进入当前发布里程碑。原文举例撰写该文档时 P0 问题会进入 1.13P1问题/特性/请求通常分配给当前或下一个发布里程碑P2 与 P3通常进入该年的第二学期即 22H2 时段可访问性与控制台类问题需要随 Windows 操作系统发布的进入当前学期处理呼应前文控制台 Bug 必须与 OS 同步的承诺其余与 22H1/22H2 学期内既有特性无关的条目进入 Backlog等待后续分诊、定优先级与排期。这套规则的实际效果是把路线图从静态文档变成了漏斗Backlog → Up Next → 22H1/22H2 学期里程碑 → 具体 6 周发布里程碑问题沿优先级从下游向上游流动。仓库佐证一特性分级Feature Staging如何兑现Preview 先行的承诺2022 路线图中特性先进 Preview、后进入 Stable是一条发布纪律在仓库源码中与之配套的机制是til::feature 特性分级系统其完整说明见 doc/feature_flags.md数据源为 src/features.xml。doc/feature_flags.md 给出的特性文档示例展示了每个feature的字段name特性名构建系统据此生成Feature_XYZ::IsEnabled()的 C 接口以及预处理器宏TIL_FEATURE_XYZ_ENABLEDstage默认状态取AlwaysEnabled或AlwaysDisabledalwaysDisabledBranchTokens/alwaysEnabledBranchTokens按分支通配符决定特性在哪些分支上被禁用/启用alwaysDisabledBrandingTokens/alwaysEnabledBrandingTokens按**品牌branding**决定特性状态文档注明有效的品牌包括Dev、Preview、Release、WindowsInboxalwaysDisabledReleaseTokens空标签用于在 Release 渠道无条件禁用。文档同时给出了优先级判定顺序alwaysDisabledReleaseTokens 启用分支 禁用分支最长匹配的分支令牌胜出 启用品牌 禁用品牌 特性默认状态。对照当前 src/features.xml 的实际内容可以看到品牌机制的具体运用以下均为该文件中的真实条目Feature_ShellCompletions对应文档 #3121即 Suggestions UI 的底层特性标记为AlwaysEnabled但带空alwaysDisabledReleaseTokens——意味着它启用、但在 Release 渠道编译掉恰好就是先在 Preview/Dev 跑、稳定后再放开的典型形态Feature_QuickFix 与 Feature_SaveSnippet 同样是默认启用 Release 禁用Feature_AttemptHandoffconhost 尝试把连接移交 OpenConsole则是AlwaysDisabled仅对WindowsInbox品牌启用——说明同一段代码在独立版 Terminal 与随 Windows 交付的版本中行为可以不同特性分级正是处理这种差异的手段Feature_ScratchpadPane、Feature_MarkdownPane 仅在Dev/Canary品牌启用属于实验性验证类特性。从源码结构看这套编译期开关让Preview 先行不只是发布渠道上的时间差更是代码层面的门控实验性能力可以先进入 Preview 品牌构建接受验证而不需要等到全部特性就绪才合入。仓库佐证二发布工程脚本与路线图术语的对应关系仓库 tools/ReleaseEngineering/ 目录下的三个 PowerShell 脚本是 2022 路线图中6 周里程碑 → Preview → Stable交付流程的工程化体现其术语与路线图高度吻合。Draft-TerminalReleases.ps1负责把一整目录的构建产物zip 包、预装 kit、MSIX bundle整理成带版本号与资产的发布。脚本头部注释说明它自动解包文件获取版本号按品牌类别归类并基于内容发布草稿。源码中可直接对照路线图术语Enum Branding { Unknown, Release, Preview, Canary, Dev }四品牌渠道枚举与 src/features.xml 中的品牌令牌体系一致按 MSIX 包名识别品牌Microsoft.WindowsTerminal→ Release、Microsoft.WindowsTerminalPreview→ Preview、Microsoft.WindowsTerminalCanary→ Canary、WindowsTerminalDev→ DevVersionMoniker {Major}.{Minor}与路线图表中1.13、1.14这类两位版本号命名一致资产类型覆盖ApplicationBundle.msixbundle、PreinstallKit、GroupPolicy、NugetPackage、Zip五类其中 PreinstallKit 会通过tar解出内部.msixbundle再解析AppxManifest.xml取版本。ServicingPipeline.ps1实现版本维护servicing流程参数包含目标$Version与$SourceBranch默认origin/main脚本内建一个交互式冲突解决 Shell对维护过程中出现冲突的提交提供done解决并提交、skip跳过、abort中止、reject跳过且从维护中移除四种处理。从源码结构看这对应路线图中Lock down bake阶段之后、以及已发布版本在维护分支上打补丁所需的工程支撑。New-TerminalStackedChangelog.ps1生成跨多个版本区间的变更日志脚本注释示例New-TerminalStackedChangelog 1.9..release-1.9, 1.10..release-1.10表明它把每个提交转成一行带致谢的条目非微软人员的提交会附上(thanks 用户名!)并支持跨区间合并时统计重复条目。这正是路线图中Release阶段发布说明Release Notes的工作工具。三个脚本合起来覆盖了路线图表中每行里程碑进入 Preview / Stable背后的实际操作构建产物归类打包Draft-TerminalReleases→ 版本分支维护ServicingPipeline→ 变更日志撰写New-TerminalStackedChangelog。后续演进从 6 周冲刺到季度节奏2022 路线图中6 周一个里程碑的模型在继任文档 doc/roadmap-2023.md 中被明确调整Weve settled on a roughly quarterly release cycle - about once every three months即约三个月一个版本的季度节奏。该文档还解释了调整背景1.18 的发布曾为对齐 Build 2023 而小幅推迟这些时间线是粗略估计而非硬性规则。两个版本路线图的对照可以总结为一句话2022 版用6 周里程碑 学期大节点 双渠道滞后一个月来描述交付节奏2023 版则将其简化为季度节奏同时保留 Preview 先行、Stable 滞后一个版本的核心原则并为高风险特性增加了可长期停留在 Preview 的例外条款该例外清单即 src/features.xml2023 文档脚注特别指出它是用于点亮代码库特定部分的原始 XML 文档并非为人类阅读而写。小结doc/roadmap-2022.md 虽已被 doc/roadmap-2023.md 取代但它完整记录了 Windows Terminal 在 2022 年的规划方法论放弃刚性 2.0 版本、以 22H1/22H2 学期对齐 OS 内部截止日期、6 周里程碑滚动交付、Preview 先行约一个月后进入 Stable、以及 P0~P3 的 Issue 分诊漏斗。结合仓库内的 src/features.xml 特性分级机制与 tools/ReleaseEngineering/ 发布脚本可以看出路线图中的每一条交付纪律都有对应的工程实现支撑这也是该文档对理解整个项目发布体系仍有独立参考价值的地方。阅读时应注意其局限文档自身声明所有日期均为粗略估计且文中所有里程碑状态22H1/22H2/Up Next/Backlog 的归属、1.13当前版本等都是 2022 年中的快照不适用于当前代码基线。【免费下载链接】terminalThe new Windows Terminal and the original Windows console host, all in the same place!项目地址: https://gitcode.com/GitHub_Trending/term/terminal创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
