为什么我非得把 Inari 的版本历史扒个底朝天？
我最近接了个硬茬子，客户要求把一套老掉牙的系统重新跑起来，这个系统核心就依赖那个叫 Inari 的玩意儿。但问题是，客户自己都不知道当时用的是哪个版本，文档更是没影儿了。我当时就懵了，如果不确定版本，那环境根本搭不起来。
没办法，我只能自己动手，把 Inari 的“版本大全”给挖出来，顺便摸清楚到底哪个版本才是官方现在还在维护的。这活儿，听着简单，干起来真是要命。
动手实操：从野路子到官方库
我一开始想图个省事，直接跑去搜索引擎里敲了“Inari 历史版本下载”。结果？出来的搜索结果，前三页全都是各种小站和论坛，点进去就是一堆弹窗广告，还有那种假冒的下载链接，一看就知道是钓鱼的。
我赶紧把那堆垃圾网站全关了，意识到走这条路就是在给自己找麻烦。我立马换了策略，直接瞄准官方渠道。我开始搜索“Inari 核心仓库”或者“Inari 开发者页面”。
花了差不多一个多小时，终于摸到了 Inari 在代码托管平台上的主页。但是新的挑战又来了：官方仓库里头，分支和标签堆得跟山一样高。他们这帮人，版本号打得稀烂，什么 Release Candidate (RC)、Alpha Preview、Stable，全部混在一块儿。
我没办法，只能从最老的提交记录开始，一个一个地点进去，核对版本发布日期，比对提交信息，确认到底哪些是他们自己盖章的“稳定版”。我用了一下午的时间，终于把那些废弃的、实验性质的版本全部给过滤掉了。光是筛查那堆标签，我的眼睛都快瞎了。
我的最终版本梳理记录
经过这么一通折腾，我才把 Inari 的版本图谱给彻底搞明白了。这家的软件有个特点，更新频率慢得像蜗牛，但是每一次大版本迭代，那架构就彻底换了一遍，兼容性差到爆。我最终整理出来的几个关键稳定版是这样的：
- v1.5.x 系列：这是最初代的核心，代码结构非常老，性能一般，但依赖库简单。如果客户那系统是十年前做的，八成就是这个。官网已经宣布死亡，但很多老系统还在用。
- v3.2.x 系列：一个过渡版本，这个版本尝试引入了新的异步处理机制，但各种小毛病不断，社区里头骂声一片。我直接标记为“高风险，建议跳过”。
- v4.6.x 系列：目前官方主推的旗舰版本。文档资料最完善，对系统环境的要求也最高。我的新项目肯定是用这个，但老系统肯定用不了。
为什么我要这么较真，花一整天去把这个版本历史给扒得这么细？
说起来，都是被坑怕了。前年我为了赶个活儿，没细看一个依赖库的版本，就随便用了个最新的。结果等系统跑起来，发现客户那边用的环境，跟我的测试环境差了小数点后两位。就因为这两位数的差别，一个关键的数据库连接接口直接报错，系统当场就瘫了。
那是周六下午，我正带着一家老小在公园里玩儿，电话就打进来了，客户在电话里头吼得跟雷一样。我立马丢下家人，赶回公司，在机房里头熬了一晚上，才发现是版本冲突惹的祸。
那次把我搞得焦头烂额，差点把那周末搞砸。从那之后，我给自己立了个规矩：凡是涉及到软件核心的，必须自己动手，从官网把它的祖宗十八代都查个清楚。这回把 Inari 的版本搞透了，以后遇到这种老系统迁移，心里就有数了，再也不会被那该死的小版本号给折磨了。