ripgrep 版本历史深度解读：从 CHANGELOG 看 rg 的演进路线、关键特性与升级注意事项

本文以 ripgrep 仓库根目录的 CHANGELOG.md 为主体，完整梳理 ripgrep 从 0.2.0 到 15.2.0 的版本演进脉络：每个里程碑版本引入了哪些核心能力、哪些行为发生了破坏性变更、各版本的最低 Rust 编译要求如何变化，并结合仓库源码验证这些变更的真实落地位置，帮助你判断当前应选用哪个版本、升级前需要关注什么。

CHANGELOG 的组织方式与维护流程

CHANGELOG.md 采用倒序排列：最新已发布版本在最上方，最旧版本（0.2.0）在最下方。文件开头是一个 TBD 段落，占位内容为 “Unreleased changes. Release notes have not yet been written.”，用于在两次发布之间累积尚未撰写发布说明的改动。

这个维护方式与 RELEASE-CHECKLIST.md 中规定的发布流程一一对应，从仓库文件可以确认以下事实：

• 发布时需要 “Update the CHANGELOG as appropriate”（见 RELEASE-CHECKLIST.md），即逐版本撰写 Platform support、Performance improvements、Feature enhancements、Bug fixes 等分类条目；
• 发布完成后要回到 CHANGELOG 顶部重新添加 TBD 段落，模板就内嵌在 RELEASE-CHECKLIST.md 中；
• 版本号的唯一权威来源是 Cargo.toml 中的 version = "15.2.0" #:version，其中 #:version 注释是构建脚本识别版本锚点的标记；
• 发布归档物（tarball、deb 包）会包含 CHANGELOG 本身，见 Cargo.toml 中 deb 包的 CHANGELOG.md -> usr/share/doc/ripgrep/CHANGELOG 安装项；
• 每个 tag 的 release notes 是从 CHANGELOG 对应段落直接复制的，并附上 ci/sha256-releases 脚本产出的校验和，用于更新 pkg/brew/ripgrep-bin.rb。

因此，阅读这份 CHANGELOG 时可以把每个版本的条目视为“已经过发布流程验证的结论”，而 TBD 段落则代表正在进行中的开发。

版本时间线总览

下表汇总 CHANGELOG 中出现的全部已发布版本（早期 0.2.x/0.3.x 版本在文档中未标注日期，表中以 “—” 表示）：

版本	发布日期	主题
15.2.0	2026-07-15	gitignore 匹配修复、超大语料目录遍历性能、musl aarch64 二进制
15.1.0	2025-10-22	修复 15.0.0 的 --line-buffered 回归；Cursor 超链接别名
15.0.0	2025-10-15	重大版本：gitignore 系列修复、full LTO 二进制、jj 仓库支持
14.1.1	2024-09-08	修复漏报匹配（false negatives）的匹配 bug
14.1.0	2024-01-06	修复 ignore crate 内存无界增长；ARM 二进制扩充
14.0.0	2023-11-26	超链接支持、正则引擎重写、--generate、参数解析库更换
13.00.0	2021-06-12	CVE-2021-3013 安全修复、Windows 静态构建、向量化 memmem
12.1.0 / 12.1.1	2020-05	补丁发布与依赖 tag 同步
12.0.0	2020-03-15	--engine 引擎切换、多个 --no-ignore-* 细粒度开关
11.0.0	2019-04-15	版本号体系从 0.x 切换为 N.0.0；退出码对齐 GNU grep
0.10.0	2018-09-07	libripgrep 诞生：PCRE2、多行搜索、--json
0.9.0	2018-08-03	--stats、-b、--count-matches、运行时 SIMD 检测
0.8.0	2018-02-11	配置文件、压缩文件搜索（-z）、true color
0.6.0	2017-08-23	--iglob、-x/--line-regexp
0.5.0	2017-03-12	非 UTF-8 编码支持（BOM 嗅探 + -E）、-M、--max-filesize
0.4.0 ~ 0.2.0	—	类型过滤、glob 语法、.ignore/.rgignore、-S、{foo,bar} glob

CHANGELOG 中还有两条值得注意的记录：0.2.4 被标记为 “SKIPPED.”（跳号未发布）；从 0.10.0 起，每个版本条目都改为链接对应的上游 issue/PR 编号，可追溯性显著增强。

15.x 系列：最近的三个版本

15.2.0（2026-07-15）

该版本聚焦 gitignore 匹配 bug 修复与目录遍历性能，CHANGELOG 原文归纳为：

• 平台支持：新增 aarch64-unknown-linux-musl 到发布二进制中；
• 性能：PERF #3293 —— 改善超大语料（very large corpora）上的目录遍历时间；
• 功能增强：FEATURE #3275 —— ripgrep 现在尊重 GIT_CONFIG_GLOBAL 与 GIT_CONFIG_SYSTEM 环境变量；
• Bug 修复：BUG #3212 —— 使用 --no-ignore 时不再检查 .jj 目录是否存在；BUG #3320/#3376/#3419 —— 修复跨多个目录搜索时 gitignore 规则匹配错误。

其中 GIT_CONFIG_GLOBAL/GIT_CONFIG_SYSTEM 支持可以直接在源码中验证：crates/ignore/src/gitignore.rs 中实现了读取逻辑——设置 GIT_CONFIG_GLOBAL 时会替换 $HOME/.gitconfig，GIT_CONFIG_SYSTEM 优先于默认的 /etc/gitconfig 路径。这对容器环境和 CI 场景影响明显：可以在不写入全局 gitconfig 的情况下，通过环境变量注入自定义 core.excludesFile，而 15.2.0 之前这两条路径是不可控的。

BUG #3212（--no-ignore 时不再探测 .jj）则说明 .jj 检测被收敛到了“忽略规则启用”的路径上，与 15.0.0 引入的 Jujutsu 仓库支持（见下文）属于同一功能面的迭代。

15.1.0（2025-10-22）

这是一个小版本，核心是修复 15.0.0 引入的行缓冲回归：--line-buffered 在某些场景下输出延迟，甚至在使用该标志的情况下也无法与 tail -f 正确协作（BUG #3194）。对依赖 rg -l --line-buffered 做实时监控的工作流，15.1.0 是 15.x 中第一个“可以放心用于流式管道”的版本。

功能侧新增了 Cursor 编辑器的超链接别名（FEATURE #3192）。超链接别名的注册机制位于 crates/printer/src/hyperlink/mod.rs，别名定义集中在 crates/printer/src/hyperlink/aliases.rs，补全脚本也会动态拉取别名列表，见 crates/core/flags/complete/zsh.rs。

15.0.0（2025-10-15）

CHANGELOG 对 15.0.0 的定性是：以 bug 修复为主、附带少量性能改进与新功能的重大版本。要点包括：

• gitignore 修复群：BUG #829/#2731/#2747/#2770/#2778/#2836/#2933/#3067 集中修复了“来自父目录的 gitignore 规则”这一长期顽疾；BUG #2750 修复超大 gitignore 文件的内存使用回归；BUG #2177 使 ripgrep 忽略 .gitignore 等文件开头的 UTF-8 BOM；BUG #3179 修复绝对路径 + 全局 gitignore 组合下的匹配 bug；
• 行为变化：rg -vf file 在 file 为空文件时，从“不匹配任何东西”变为“匹配一切”；-r/--replace 现在与 --json 兼容（FEATURE #1872，此前是 15.0.0 之前一直未解决的功能请求）；
• Jujutsu 支持：FEATURE #2842 —— 含 .jj 目录的子集仓库现在被视为 git 仓库，即 ripgrep 会尊重 jj 的 gitignore。源码证据在 crates/ignore/src/dir.rs：目录扫描时 has_jj_dir 与 git 目录检测并列，has_git = check_vcs_dir && (git_type.is_some() || has_jj)，测试用例 gitignore_with_jj 位于同文件（dir.rs）；
• glob 增强：FEATURE #3048 —— ripgrep 及 globset crate 支持嵌套花括号交替（nested alternates），对应源码在 crates/globset/src/glob.rs；
• 平台/构建：Windows 新增 aarch64 产物；powerpc64 产物因 CI 失效被移除；发布二进制改用 full LTO 编译——这与 Cargo.toml 中的 release-lto profile（lto = "fat"、codegen-units = 1、panic = "abort"）一致，CHANGELOG 称其带来小幅性能提升与体积下降。

15.0.0 的其他修复还包括：--stats 的 “bytes searched” 计数错误（BUG #2944）、以 . 结尾的 glob 处理错误（BUG #2990）、-m 与 -U 组合多显示匹配（BUG #2094/#3076）、-r 保留行结束符（BUG #3100）、-q --files-without-match 退出码反转（BUG #3108）、-U + -r 的 panic（BUG #3180），以及为 --color 增加 italic 属性与 highlight 颜色类型（FEATURE #2841/#3024）。

14.0.0：超链接、正则引擎重写与 --generate

14.0.0（2023-11-26）是 CHANGELOG 中篇幅最长的重大版本，其三大头条值得单独展开：

1）超链接支持（opt-in）。 新增 --hyperlink-format 标志（FEATURE #665），把输出中的文件路径变成 OSC-8 超链接；--hyperlink-format default 生成 RFC 8089 的 file://{host}{path} 形式，--hyperlink-format vscode 则适配 VS Code。该标志的定义与帮助文本在 crates/core/flags/defs.rs，运行时插值逻辑（{{path}}、{{column}} 等变量）在 crates/printer/src/hyperlink/mod.rs。CHANGELOG 特别注明：14.0.0 中超链接是 opt-in，未来可能改为 opt-out。14.1.1 之后的 15.x 继续迭代此机制（如 15.1.0 的 Cursor 别名）。

2）正则引擎重写。 14.0.0 包含对其正则引擎的重写，CHANGELOG 称“通常不会察觉变化，但部分搜索会更快”。从源码结构看，重写后的引擎落在 workspace 内的 crates/regex（即 grep-regex），其 crates/regex/src/literal.rs 的注释明确对比了 “ripgrep <=13 的旧实现” 在 inner literal 提取上的差异。这个重写也为 14.1.1 的匹配 bug 埋下伏笔（见下节）。

3）参数解析库更换。 用户层面几乎无感（错误信息措辞变化），但标志覆盖（override）行为变得更一致，例如 --no-ignore --ignore-vcs 按字面预期工作：禁用所有 ignore 规则过滤，但保留 VCS（如 git）中的规则。

破坏性变更：rg -C1 -A2 过去等价于 rg -A2（-A/-B 完全覆盖 -C），14.0.0 起变为 rg -B1 -A2——-A/-B 只部分覆盖 -C。

构建流程变化：shell 补全与 man page 改由 rg --generate 生成（如 rg --generate man 输出 roff 格式的 man page），去掉了对外部 asciidoc/asciidoctor 的可选构建依赖——对应源码即 crates/core/flags/complete/ 下各 shell 的 generate() 函数与 crates/core/flags/doc/man.rs。这也是后续 14.0.x 连续三个补丁版本（14.0.1 修复 cargo install 缺少 pkg/windows/Manifest.xml 打包、14.0.2 修复 --null-data --line-regexp 行为回归与 fish 补全、14.0.3 修复 --sortr=path 遗漏的 todo!()）集中清理的构建产物问题。

性能侧，14.0.0 引入了并行目录遍历的 work stealing（PERF #2591）与争用削减（PERF #2642），以及针对 \b 等 look-around 的大量提速（PERF #1760）。

14.1.1：一个关于“漏报”的重要警告

14.1.1（2024-09-08）修复的是 BUG #2884：ripgrep 可能漏报本应匹配的行（false negatives）。CHANGELOG 给出的具体案例是：正则 (?i:e.x|ex) 应当匹配 e-x，但在某些优化策略组合下不匹配。值得注意的是，CHANGELOG 明确指出该 bug 源于 grep-regex crate 的 inner literal 优化，而非底层 regex crate——这解释了为什么它需要多个优化策略“碰撞”才触发，难以被常规测试覆盖。如果你的工作流依赖精确的否定性结论（“确实没有匹配”），升级到 14.1.1+ 是必要动作。该版本的 Miscellaneous 条目还移除了长期“频繁损坏”的 simd-accel 构建特性。

13.0.0：安全修复与版本策略的延续

13.0.0（2021-06-12）的头条是 CVE-2021-3013：在 Windows 上使用 -z/--search-zip 或 --pre 时，可能执行当前目录中的任意可执行文件。这是 ripgrep CHANGELOG 中唯一记录的安全公告（对应公开 issue #1773），之后 README 增加了漏洞报告说明。如果你仍在使用 13.0.0 之前的版本且启用了 --pre，升级理由充分。

13.0.0 的其他要点：

• 新增短标志 -. 作为 --hidden 的别名；
• 换用向量化 memmem 实现，加速大量常见搜索；
• MSVC 目标改为构建完全静态的可执行文件；
• 破坏性变更：二进制文件检出提示从 Binary file FOO matches ... 变为 FOO: binary file matches ...（解析 rg 输出的脚本需要注意）；多行模式下 --vimgrep 每个匹配只打印首行；多行模式下 --count 语义等同于 --count-matches。

11.0.0 与 12.0.0：版本号体系与引擎选择的定型

11.0.0（2019-04-15）标志着版本号的体系切换：从 0.10.0 直接跳到 11.0.0，之后每年数次递增主版本号，并承诺对向后兼容保持保守、但破坏性变更会始终记录在 CHANGELOG（issue #1172 记录了动机）。该版本的破坏性变更至今仍影响脚本编写者：

1. 退出码对齐 GNU grep：搜索中出现非致命错误时，无论是否找到匹配，退出码均为 2（此前仅灾难性错误如正则语法错误才返回 2）。例外：-q/--quiet 下若发生错误但找到了匹配，退出 0；
2. -uuu 语义变化：三次 -u/--unrestricted 等价于 --no-ignore --hidden --binary（之前是 --no-ignore --hidden --text）。CHANGELOG 强调 rg -uuu foo 从此应与 grep -r foo 等价；
3. MSRV 从 1.28.0 提升到 1.34.0。

11.0.0 同时新增了 --binary、--max-columns-preview、-z 对 Brotli/Zstd 的支持、--auto-hybrid-regex（自动回退 PCRE2）、-I 短标志、-E none 等；修复了非法 UTF-8 上的死循环（11.0.1 紧急补丁，BUG #1247）、-F 与元字符的匹配回归（11.0.2，BUG #1334）以及 x86_64-linux 发布二进制的性能回归（BUG #1268）。

12.0.0（2020-03-15） 引入 --engine 标志用于在不同正则引擎（default/PCRE2/auto）间切换，并废弃 --auto-hybrid-regex 与 --no-pcre2-unicode（改用统一的 --no-unicode，对所有引擎生效）。新增的细粒度忽略开关构成一套组合拳：--no-require-git（在任意位置尊重 gitignore）、--no-ignore-exclude（忽略 .git/info/exclude）、--no-ignore-files、--include-zero、--no-context-separator。性能修复 BUG #1335 特别关键：搜索超长行的纯文本文件时的严重性能回归。CHANGELOG 还在 12.0.0 中预告了索引功能（issue #1497）——从源码结构看，该功能的实验性实现至今以 unstable-index 特性存在于 Cargo.toml（“currently in active development and may have very serious bugs”）与 crates/index 中，尚未成为默认能力。

0.x 时代：能力基座是如何搭起来的

0.2.0 至 0.10.0 是 ripgrep 能力基座的成型期。按 CHANGELOG 各版本的核心新增归纳：

版本	核心能力
0.2.0	--no-filename、--files-with-matches、从 .rgignore 转向 .ignore（保留但弃用）、-S/--smart-case、{foo,bar} glob
0.2.2	进入 homebrew-core 与 Arch 社区仓库；glob 匹配抽离为独立 globset crate；--max-depth、-s
0.2.5	全局 gitignore 配置与 .git/info/exclude 支持；--ignore-file；ignore crate 独立封装 gitignore 匹配逻辑
0.2.7	并行递归目录迭代器（PERF #223，大仓库性能质变的起点）；bytecount 换行计数（部分场景提速一倍）；-m/--max-count、--no-messages
0.3.0	参数解析从 Docopt 迁到 Clap（Rust 1.11）；-f/--file、--colors、--files-without-match；小语料下性能追平 GNU grep（PERF #33）
0.4.0	regex 依赖升 0.2：POSIX 字符类需双括号 [[:upper:]]；类型定义可互相引用；--sort-files、--path-separator
0.5.0	非 UTF-8 编码支持：BOM 嗅探自动检测 UTF-16，-E/--encoding 支持 latin-1、GBK、EUC-JP、Shift_JIS 等；-M/--max-columns、--max-filesize
0.6.0	--iglob、-x/--line-regexp（匹配需跨整行）
0.8.0	配置文件支持（标志覆盖规则改为“最近的竞争标志获胜”）；-z/--search-zip 压缩文件搜索（gzip/bzip2/lzma/xz）；true color（Windows 10）；.rgignore 回归为高优先级应用级忽略文件；ARM 二进制；新增 GUIDE.md 与 FAQ.md
0.9.0	--stats、-b/--byte-offset、--count-matches、--no-column、-z 支持 lz4、--no-ignore-global、--pre（用任意程序过滤输入）；x86_64 二进制改为运行时特性检测（AVX2 等），全 CPU 可用
0.10.0	libripgrep 诞生：核心搜索/打印代码重写并泛化为可复用 crate（grep crate）；-U/--multiline 多行搜索；-P/--pcre2（look-around 与反向引用）；--json（JSON Lines 输出）；--one-file-system、--sort/--sortr、--crlf、--null-data、--pre-glob、--line-buffered/--block-buffered

从这张表可以看出 ripgrep 的能力分层：0.2.x 解决“遍历与过滤”（ignore/globset crate），0.5.0~0.8.0 解决“输入形态”（编码、压缩、配置），0.9.0 解决“输出与统计”，0.10.0 之后才进入“输出形态与可编程性”（JSON、多行、PCRE2），并在 11 以后进入“生态集成”（超链接、索引、其他 VCS）。

破坏性变更速查表

CHANGELOG 在各版本的 BREAKING CHANGES 小节中累计记录了以下用户可感知的行为变化（按版本）：

版本	破坏性变更
0.3.0	-e 不再接受以 - 开头的模式（绕过：rg -- -foo 或 rg -e [-]foo）；要求 Rust 1.11
0.4.0	正则语法：POSIX 类需 [[:upper:]] 双括号；字符类内 [ 必须转义；--column 隐含 --line-number
0.5.0	仅搜索 stdin 且输出到 tty 时，行号默认隐藏
0.8.0	竞争标志“最近者获胜”（rg foo -s -i 变为不区分大小写）；--max-columns=0 从“抑制所有非空匹配行”变为“等同于未设置该标志”；glob 中 [^...] 等同 [!...]；发布归档目录结构变化（man page/guide/FAQ 移入 doc/）
0.9.0	--count + -o 同时给出时行为等同 --count-matches（与 GNU grep 分歧）；移除八进制语法（\1 报错）；移除 --line-number-width
0.10.0	-w 匹配语义从 \b(p)\b 变为 `(^
11.0.0	退出码对齐 GNU grep（非致命错误恒为 2）；-uuu = --no-ignore --hidden --binary；MSRV 1.34.0
13.0.0	二进制检出输出格式变化；多行 --vimgrep 每匹配只打印首行；多行下 --count = --count-matches
14.0.0	-C1 -A2 不再被 -A 完全覆盖，等价于 -B1 -A2；shell 补全与 man page 改由 rg --generate 生成，弃用 asciidoc 构建依赖

升级时的实操建议：如果你的脚本解析 rg 的退出码或输出文本，逐行核对上表即可定位风险点；其中 11.0.0 的退出码语义与 13.0.0 的二进制提示格式是自动化场景中最容易踩坑的两条。

版本选择与编译要求的演进

CHANGELOG 中分散记录的 MSRV（最低支持 Rust 版本）变化可作为编译侧的参考坐标：0.6.0 要求 1.17 → 0.8.0 要求 1.20 → 0.9.0 要求 1.23 → 11.0.0 要求 1.34 → 0.10.0 起改为“跟踪最新 stable”。当前仓库 Cargo.toml 的 workspace 配置为 edition = "2024"、rust-version = "1.96"，即从源码构建当前版本需要 Rust 1.96+。

对使用者的选择建议（基于 CHANGELOG 的定性描述，非性能承诺）：

• 日常使用：选最新 patch/minor（当前为 15.2.0）。CHANGELOG 显示最近的三个版本都在修复 gitignore 匹配与行缓冲这类“正确性”问题，对任何版本的用户都有实际收益；
• CI 环境：关注 15.2.0 的 GIT_CONFIG_GLOBAL/GIT_CONFIG_SYSTEM 支持，可用环境变量精确控制 gitignore 来源，避免污染用户主目录配置；
• 从 14.x 以下升级：先核对上面破坏性变更表中的退出码与输出格式条目，再跑一遍现有脚本；
• 使用 -z/--pre 的历史版本：若低于 13.0.0 且运行于 Windows，CVE-2021-3013 的修复是硬性的升级理由。

结语：CHANGELOG 作为行为契约的价值

ripgrep 的 CHANGELOG.md 不止是版本流水账：它以“破坏性变更 + 逐 issue 可追溯 + 发布流程内嵌检查”的三重机制，事实上充当了 rg 输出行为的契约文档。结合 RELEASE-CHECKLIST.md 可以看到，每个 tag 的发布 notes 直接取自 CHANGELOG 对应段落，发布流程还强制在 tag 推送前核对 crates/ 下所有子 crate 的变更。对维护依赖 rg 的自动化流水线或终端工具的开发者而言，跟踪这份 CHANGELOG（尤其 TBD 段落与最新的破坏性变更小节）是比关注任何单一 issue 更可靠的升级决策依据。