最近我手上那个跑了三年的老系统，突然就给我撂挑子了。不是什么大毛病，就是跑某个新模块的时候，老是报一些莫名其妙的兼容性错误。一开始我以为是驱动的问题，花了两个晚上去换驱动、更新内核，结果屁用没有。我才反应过来，可能是我的Inari版本太老了，跟不上社区最新的组件迭代了。
我当时就决定，既然要升级，就一步到位，搞个最新的稳定版。我这个人做事，要么不干，要干就得搞清楚来龙去脉。结果，当我打开Inari的官网下载页面时，我直接傻眼了。这哪里是官网，简直就是个版本历史博物馆。各种分支、RC版、Beta版，还有好几个看起来像官方但是社区维护的版本，一股脑堆在一起，完全没有清晰的稳定版推荐路径。
我当时心里就冒火了，这不是浪费时间吗？我只是想找个能用的版本，结果还要自己去猜哪个是真货。但我转念一想，与其抱怨，不如自己动手，彻底把这事儿捋一遍，也省得以后再掉坑。于是我决定，要把官网所有的版本信息，从头到尾，挨个儿扒下来，做个大全。
第一次摸索，差点放弃
我最开始的想法很简单，就是手动从下载页面往后翻。我点进去了“历史归档”那个小小的链接。果然，里面是按年份文件夹分的。我打开了2018年的文件夹，又打开了2019年的，一个个文件夹点进去，文件名密密麻麻，只有版本号和日期。那个工程量，我干了两个小时，眼睛都快花了，才勉强把主要的几个大版本号记下来。
更恶心的是，有些版本的命名规则非常不统一，有些是“vX.Y.Z”，有些突然变成了“YearMonthDay”这种格式。我意识到，光靠肉眼这么看，绝对会漏，而且容易出错。
当时正好是周末，我老婆在客厅里看剧，看我对着屏幕眉头紧锁，问我是不是又遇到bug了。我跟她说了我要给Inari做个版本大全，她笑着说：“你这人，修个机器非得把人家祖坟都刨出来。”我心想没错，这回我就要刨个底朝天。
决定动手，系统性抓取
既然手动不行，那就得找个稍微系统点的办法。我当时没想着去写什么复杂的脚本，那太费劲了。我搬出了我的老三样：一个文本编辑器，一个好的浏览器开发者工具，和一个大大的Excel表格。
我定位了官网归档页面的结构，发现所有的版本记录都是嵌在一个巨大的列表里的。虽然没有直接的API接口给我用，但是浏览器加载数据的时候，把所有的版本信息都堆在了一个大块的HTML里。我右键点击，然后选择了“查看页面源代码”。
这下就简单多了。我把整坨代码复制出来，粘贴进我的文本编辑器里。然后我开始用查找替换功能，像筛沙子一样，把里面那些没用的标签和文字全部清理掉。我主要抓以下几个关键信息：
- 定位版本号：所有版本号前面都有一个特定的字符串标识，我用这个标识来定位每一行。
- 提取日期戳：找到对应的发布日期，这个非常重要，因为有些版本号很接近，日期是区分稳定性的关键。
- 核对分支名称：区分主线稳定版、社区LTS版和开发测试版。这是最花时间的步骤，因为名字很像，我不得不交叉比对社区论坛里的官方声明。
我足足花了六个多小时，一直干到凌晨一点多，才算把主要的稳定版信息都清洗出来。我把这些干净的数据一行行填进我的Excel表格里。表格里不仅有版本号、发布日期，我还自己加了一列“社区评价”，就是我根据论坛里大家的反馈，给这个版本的稳定性打个分。
最终的清单和实践收获
当我把这个几十行的版本大全表格整理完的时候，那种成就感别提多踏实了。我不再需要去官网像无头苍蝇一样乱撞了。我的表格清清楚楚地告诉我：
最新的稳定推荐版本是 X.Y.Z，它解决了我老版本系统里的那个兼容性缺陷。
通过这回实践，我发现官方文档不清晰，那是常事。但是只要你自己动手，找到数据源，用最笨最直接的办法把数据抓出来、清理干净、再重新组织，你就能得到一个比官方更实用、更符合你自己需求的“手册”。这个版本大全我现在就放在我的个人云盘里，以后再有谁问Inari哪个版本最稳定，我直接把这表甩过去，比我说一百句话都管用。实践出真知，一点没错。