从 browser-logos 的 edge-beta CHANGELOG 解析开源 Logo 包的版本演进与发布自动化

• 前端

browser-logos是一个以"高分辨率浏览器 Logo"为核心资产的开源仓库（根目录见 README.md），每个 Logo 以独立 npm 包形式维护，目录内固定包含README.md、package.json、CHANGELOG.md与多尺寸 PNG 产物。本文以@browser-logos/edge-beta包（即 Microsoft Edge Beta 浏览器 Logo）的 CHANGELOG.md 为主线，完整还原这份变更日志从 1.0.0 到 2.0.2 共 15 个版本的演进轨迹，并结合 scripts/release.js 的源码，讲清"emoji 提交标签如何映射到变更分类""语义化版本号如何被自动决定""CHANGELOG 条目如何被脚本自动生成并写回文件"等底层机制。读完你既能读懂仓库中任意一个包的版本史，也能掌握这套可复用的"发布即自动生成 CHANGELOG"工程实践。

一、先定位：这份 CHANGELOG 属于哪个包、管什么资产

在深入版本条目之前，先明确该变更日志的"服务对象"。它位于 src/edge-beta/CHANGELOG.md，对应的是当前仓库中处于"现行（Current）"状态的 Microsoft Edge Beta 浏览器 Logo 包，与其配套的 src/edge-beta/package.json 声明了关键元信息：

• 包名：@browser-logos/edge-beta
• 当前版本：2.0.2
• 描述：Microsoft Edge Beta browser logo
• 关键词：browser-logos、logo、microsoft-edge-beta、microsoft-edge-beta-logo
• 仓库目录：src/edge-beta

与仓库内多数包一样，该目录的实物资产是一组不同分辨率的透明背景 PNG（edge-beta.png主图 1024×1024，以及_16x16、_24x24、_32x32、_48x48、_64x64、_128x128、_256x256、_512x512共 8 个派生尺寸），在 src/README.md 的 Edge 分区中与edge、edge-dev、edge-canary并列展示。也就是说，这份 CHANGELOG 记录的是"这一个 Logo 资产包"从首次发布以来的每一次修改与发布决策，是理解该包质量演进的权威时间轴。

二、CHANGELOG 的结构骨架：一个可被脚本解析的固定格式

打开 src/edge-beta/CHANGELOG.md 可以看到它的格式高度统一，这正是为了配合 scripts/release.js 做自动化读写而设计的。整体分为三层：

1. 文件头部固定占位：首行<!-- markdownlint-disable line-length -->用于关闭 markdownlint 对超长行的检查（因为变更条目往往包含长 commit SHA 与链接）；随后是Changelog标题与其下的=========下划线。
2. 版本条目：每个版本以版本号 (月份 日期, 年份)作为一级标题，例如2.0.2 (July 11, 2020)，紧接着一行与标题等长的-----分隔线。
3. 分类小节与条目：小节标题为### Breaking Changes、### Bug fixes / Improvements或### New features；每条变更以列表项呈现，格式为* [commit 短 SHA] - 变更描述 (by 作者 / see also: issue 引用).，其中短 SHA 为完整 40 位 commit SHA 的前 10 位。

这一格式并非随意约定。scripts/release.js 中的getReleaseNotes()明确按该结构解析：头部固定为 8 行（markdownlint 注释、空行、Changelog、=========、空行、版本标题、分隔线、空行），从第 9 行起逐行收集变更内容，直到遇到形如/^(\d\.?){3}/的"下一个版本号"为止——也就是说，脚本只需要读取文件，就能把"最新一个版本"的 release notes 原样抽取出来，用作 GitHub Release 的正文。理解了这份约定，你也就理解为什么仓库里所有包的 CHANGELOG 长得一模一样。

三、版本演进时间线：从 1.0.0 首版到 2.0.2 的 15 次发布

把 src/edge-beta/CHANGELOG.md 的全部条目按时间顺序整理如下（下划线内容为原始条目要点，emoji 为提交标题的语义标签）：

从中可以归纳出三个值得注意的观察点：

• 1.0.x 阶段以"SVG 无损优化"为主旋律：连续 1.0.2～1.0.7 六个补丁版本都围绕edge-beta.svg的压缩与优化（emoji 🗜/🗜️ 即"压缩优化"语义）。这符合 SVG 型 Logo 资产迭代的典型节奏——视觉不变，只做体积与结构优化。需要说明的是，从当前仓库文件列表看，src/edge-beta/ 目录最终保留的是 PNG 产物与文档，并未包含edge-beta.svg源文件；仓库中仍能找到的 SVG 是归档包中的旧版源文件 src/archive/edge-beta_12-18/edge-beta_12-18.svg。可以推断早期版本曾以 SVG 为源资产，后续发布策略调整为直接交付 PNG。
• 2.0.0 是唯一一次破坏性变更：它在发布说明中明确以Breaking Changes分类出现，理由是"更新 Edge Beta Logo"。也就是说，这次不是优化而是视觉层面的替换（Edge Beta 频道的品牌图标换代），因此按语义化版本规则升了大版本号。
• 文档与打包细节也会驱动发版：1.0.8（README 一致性）、1.0.10（package.json 指定目录）、1.0.11（新增 Yarn 安装说明）看似琐碎，但在"npm 包即产品"的维护模式下，文档可读性与打包元数据同样值得走完整发布流程。

四、emoji 提交标签 → 变更分类：一套隐式的语义标签体系

CHANGELOG 里的每条记录都带有 emoji 前缀（💥、🐛、📚、🔧、🗜、✨），它们不是装饰，而是决定条目归入哪个分类、进而决定版本号如何递增的关键信号。scripts/release.js 中的getChangelogData()给出了官方映射：

• 💥→ 归入Breaking Changes（破坏性变更）
• 🐛（Bug 修复）、📚（文档）、🔧（配置/元数据调整）、🗜（压缩优化）→ 归入Bug fixes / Improvements（缺陷修复与改进）
• ✨→ 归入New features（新功能）
• 🚀属于特殊发布标签，仅当用于整仓库（非单包）发布时并入新功能分类

标签的来源在 scripts/release.js 的extractDataFromCommit()中：脚本取 commit 标题（git show --no-patch --format=%B的首行）的第一个字符作为tag——由于 emoji 由码点表示，[...title][0]恰好能取到它。同时该函数还用正则/(Fix|Close)\s+#([0-9]+)/gi扫描 commit 正文，提取关联的 issue 编号，这才有了条目末尾"see also: #181"这类引用。

对照 src/edge-beta/CHANGELOG.md 可以看到该映射的落地结果：2.0.0 条目带 💥，被归入### Breaking Changes；其余条目带 📚/🔧/🗜，全部归入### Bug fixes / Improvements；1.0.0 首版只有 ✨。这份变更日志里没有出现### New features小节，正说明该包自发布以来从未增加新功能，只有改进与一次品牌替换——标签体系与实际条目完全对得上。

五、语义化版本号：不是人工拍脑袋，而是脚本算出来的

版本号为什么要这么跳？scripts/release.js 给出了确定性的规则：

• 默认按patch（补丁号）递增；
• 只要存在破坏性变更（💥），就升级为major（主版本号 +1）；
• 否则若存在新功能（✨），则升级为minor（次版本号 +1）；
• 都不存在则不产生 release notes，发布任务被跳过（ctx.skipRemainingTasks = true）。

把这个规则套回 edge-beta 的时间线，一切就说得通了：1.0.x 时代全是 🐛/📚/🔧/🗜 类改进，因此一直在 patch 位（1.0.1 → 1.0.2 → … → 1.0.11）；2.0.0 引入 💥，于是主版本号直接跃升；2.0.1、2.0.2 又是改进类，回到 patch 位递增。可见这份 CHANGELOG 本身就是"提交语义 → 版本号"规则的可视化档案：只要读懂 emoji，就能预判下一个版本号该往哪跳。

六、发布流水线：release.js 如何"写"出这份 CHANGELOG

这份变更日志不是维护者手工维护的，而是 scripts/release.js 自动化流水线的产物。按 scripts/release.js 的任务编排，每个包的发布流程大致如下：

1. 获取自上次发布以来的 commit：通过git rev-list main...<首次提交SHA>^ <包路径>圈定该包目录内自上次发布后的全部提交（getCommitSHAsSinceLastRelease），再逐个解析标题、标签与关联 issue。
2. 生成 release notes 并决定 semver 增量：即上文第三节、第四节描述的分类与版本号推导（getReleaseData）。
3. 更新 package.json 版本号：执行npm version <major|minor|patch> --no-git-tag-version（npmUpdateVersion），输出形如vX.X.X再去掉v前缀。
4. 更新 README：用git log -n 1拿到的最新 40 位 commit SHA，通过sed替换 README 中旧图片链接里的 SHA（updateReadme）。
5. 更新 CHANGELOG：updateChangelog()把固定头部<!-- markdownlint-disable line-length -->\n\nChangelog\n=========\n\n与新生成的版本条目拼接，再追加原文件从第 6 行起的旧内容——于是最新版本永远出现在文件顶部，历史按倒序堆叠，与 src/edge-beta/CHANGELOG.md 的版式完全一致。
6. 人工 review 后收尾：等待维护者确认，然后git commit（提交信息为🚀 <包名> - vX.X.X）、打 git tag、npm publish（支持 OTP 一次性口令输入，首次发布需--access public）、git push推送上游，并在是整仓库发布时创建 GitHub Release（正文即解析出的 release notes）。

值得单独说明的是首次发布（1.0.0）的特殊路径：未发布包在package.json中带有"private": true标记。流水线检测到该标记后，会先移除private字段（npmRemovePrivateField），并把 CHANGELOG 新条目直接写成单个 ✨ 符号（ctx.packageReleaseNotes = '✨'）——这正是 src/edge-beta/CHANGELOG.md 中 1.0.0 条目只有一行✨的原因：首版不逐条罗列，只用 ✨ 宣告包的诞生。

此外，scripts/prepare-for-publishing.js 负责为新加入的包自动生成package.json与README.md（含 npm/Yarn 安装命令与 cdnjs 推荐、按包名美化的标题），这解释了为什么仓库中每个包目录的结构都惊人地一致，也让 CHANGELOG 里反复出现的"README 一致性小改"条目有了上下文。

七、两次 cdnjs 决策：一个被记录在案的分发渠道权衡

版本时间线里有一对"矛盾"条目值得展开：2.0.1（2019-11-30）移除了 cdnjs 推荐，并关联 issue #181；2.0.2（2020-07-11）又重新添加了 cdnjs 使用推荐。从 src/edge-beta/README.md 当前内容看，最终状态是"可以选用 cdnjs"（Use cdnjs.），说明仓库在"是否推荐第三方 CDN 分发"这一策略上经历了一次往返：先是出于某种原因（对应 issue #181 的讨论）撤回推荐，随后又恢复。这是变更日志作为"决策留痕"的典型价值——纯看 README 只能知道现状，只有 CHANGELOG 能告诉你这条策略曾被动摇过。同样的两条 commit（移除与添加）也出现在归档包 src/archive/edge-beta_12-18/CHANGELOG.md 中，从源码结构看，当前包与归档旧版包在 2019 年底存在一段共享的历史版本线。

八、配套资产与多尺寸产物：CHANGELOG 之外还管理着什么

理解 CHANGELOG 的演进，最好连同它"监护"的资产一起看。当前 src/edge-beta/ 目录包含：

• 文档与元数据：README.md、CHANGELOG.md、package.json
• 主图edge-beta.png（1024×1024，透明背景）
• 8 个派生尺寸：16、24、32、48、64、128、256、512（正方形）

这 8 个尺寸不是手动画出来的。scripts/generate-images.sh 中固定了IMAGE_SIZES数组，并用一组 ImageMagickconvert参数（-colorspace RGB、+sigmoidal-contrast 11.6933、Sinc/Jinc 滤波三叶窗、-colorspace sRGB、透明背景、居中重力）从主图高质量重采样生成每个尺寸；若目录下还缺少主图会直接报错终止。换言之，CHANGELOG 里那些"SVG 优化"类条目最终服务的，正是这一套多尺寸 PNG 的产出质量与体积。

九、如何获取并使用 edge-beta 这个 Logo 包

对于只关心"怎么用"的读者，按 src/edge-beta/README.md 与根目录 README.md 的说明，获取该 Logo 有两种主流方式：

• 通过包管理器安装（推荐用于项目构建链）：
  • npm：npm install --save-dev @browser-logos/edge-beta
  • Yarn：yarn add --dev @browser-logos/edge-beta
• 直接使用 cdnjs 上的 browser-logos 库资源（无需安装，适合静态页/CDN 引用）。

安装后即可在node_modules/@browser-logos/edge-beta/下按需引用对应尺寸的 PNG（如edge-beta_256x256.png），用于演示文稿、博客配图、站点品牌墙等场景。若需要更早时期（2012–2018 风格）的 Edge Beta Logo，可前往归档目录 src/archive/edge-beta_12-18 获取旧版资产及其独立的 CHANGELOG.md。

十、阅读任何浏览器 Logo 包 CHANGELOG 的可复用方法

把上文的方法论抽象出来，你可以在仓库任意包（如 src/edge/CHANGELOG.md、src/firefox/CHANGELOG.md）上复用它：

1. 看头部格式：确认是否为"固定 8 行头 + 倒序版本条目"标准结构，据此可手工或脚本抽取最新 release notes。
2. 看版本号跳跃：找到 major 版本，对应的必然是 💥 破坏性变更——通常意味着视觉替换、格式切换等不可向后兼容的改动。
3. 看 emoji 分布：密集的 🗜/🔧 说明该包处于"资产优化期"，密集的 📚 说明处于"文档与打包打磨期"，出现 ✨ 则说明新增了能力。
4. 对照 package.json：package.json 中的version应与 CHANGELOG 最新条目的版本号一致（当前均为 2.0.2），这是校验仓库自洽性的快速手段。
5. 关联发布脚本：需要复刻该发布体系时，以 scripts/release.js、scripts/prepare-for-publishing.js、scripts/generate-images.sh 三份脚本为蓝本——它们分别覆盖"版本发布与 CHANGELOG 生成""新包脚手架初始化""多尺寸图片产物生成"，且全部可在根目录 package.json 的 npm scripts 中找到入口（release、prepare-for-publishing、check-links、lint-markdown等）。

综上，src/edge-beta/CHANGELOG.md 远不止一份"改了什么"的流水账：它是语义化版本策略、emoji 标签约定、自动化发布流水线三者交汇的产物。读懂它，就等于同时读懂了 browser-logos 仓库的工程纪律——这也是这套项目能够长期维护上百个 Logo 包而不失序的关键所在。

• 前端