3、源码获取与版本选择：官方源码仓库、LTS版本选择策略、版本号解读、Release Notes分析

好，咱们进入第三章。这一章聊的是「选版本」这件事。

你可能觉得，选个版本有什么好讲的？去官网下载最新的不就完了？

嗯，我当年也是这么想的。直到有一次，我在一个ARM Cortex-M3的项目里，直接拉了个最新的BusyBox 1.33.x。结果编译完一跑，串口驱动死活不工作。查了两天，发现是那个版本对旧内核的兼容性做了调整，而我用的内核偏偏是2.6.35……

从那以后，我养成了一个习惯：选版本之前，先看Release Notes，再查LTS路线图。

BusyBox的官方源码托管在git上。我个人习惯直接去这个地址：

git://busybox.net/busybox.git

或者用https方式：

https://git.busybox.net/busybox/

你也可以直接访问官网 https://busybox.net，上面有下载链接和源码浏览入口。

这里有个小细节：官方仓库里不仅有master分支，还有各个版本的tag。 比如 1_35_0、1_36_1 等等。你直接用 git tag 就能看到所有版本列表。

我的习惯： 从来不用master分支做产品。master是开发分支，可能随时有bug。我只用打了tag的稳定版。

BusyBox官方并没有像Linux内核那样明确标注「LTS版本」。但根据社区惯例，偶数版本号（比如1.34.x、1.36.x）通常更稳定，维护周期也更长。

为什么会这样？说白了，BusyBox的版本号策略是：

我在项目中遇到过好几次，客户非要追新用奇数版，结果上线后出现莫名其妙的内存泄漏。后来我强制规定：产品级项目，只选偶数版本。

注意： 如果你用的是非常老的内核（比如2.6.x），建议选1.30.x之前的版本。新版本BusyBox对旧内核的支持越来越弱。我曾经在2.6.35内核上编译1.36.x，结果mount命令直接报错。

BusyBox的版本号格式是 主版本.次版本.补丁版本，比如 1.36.1。

举个例子：1.36.1 表示这是1.36稳定版的第一个补丁版本。如果你看到 1.36.0，那就是该稳定版的初始发布。

另外，有些版本后面会带 -git 后缀，比如 1.36.0-git。这表示是从git仓库直接拉取的开发中版本，千万别用在产品里。

很多工程师下载源码后，直接解压编译，从来不看Release Notes。我建议你改掉这个习惯。

Release Notes通常放在源码根目录的 docs/ 文件夹下，或者直接看官网的Changelog。里面会列出：

我曾经踩过一个坑：BusyBox 1.33.0 的 ps 命令改了输出格式，导致我项目里的监控脚本全部失效。如果当时我看了Release Notes，就能提前适配。

  我的建议： 每次升级版本前，把Release Notes里标有「Incompatible Changes」的部分截图保存。等升级完成后，对照着改你的脚本和配置。

下面这张图，是我自己总结的版本选择流程。你照着走，基本不会出错。

这张图的核心逻辑很简单：产品项目走右边，实验项目走左边。 但无论走哪条路，Release Notes这一步都不能省。

最后，分享几个我亲身经历过的教训：

坑一： 我曾经直接用了1.35.0（奇数版）做产品，结果发现 telnetd 有内存泄漏。后来查了邮件列表，发现社区在1.35.1里才修复。所以，奇数版真的只适合玩玩。
坑二： 有一次我升级BusyBox，没看Release Notes，结果 ifconfig 的输出格式变了，导致我公司的网络监控脚本全部报错。从那以后，我每次升级前都会把Release Notes打印出来，逐条核对。
坑三： 有个客户非要在一个MIPS架构的老路由器上跑最新版BusyBox。我编译完发现 ash shell 无法处理某些特殊字符。后来查了才知道，新版本对MIPS的优化不够。所以，选版本时也要考虑目标架构。

一个小技巧： 如果你不确定某个版本是否适合你的项目，可以去BusyBox的邮件列表（busybox@busybox.net）搜一下。输入你的架构和版本号，看看有没有人报过bug。我经常这么干。

好了，这一章就到这里。记住：版本选对了，后面裁剪、编译、调试都会省很多事。 下一章我们聊聊怎么配置BusyBox，让它只编译你需要的功能。