为何Maven将RELEASE版本解析为commons-io的首个版本？

这问题确实挺闹心的——好好用了多年的依赖突然抽风，还全员中招，关键是没碰过Maven版本。我来帮你捋捋可能的原因和解决办法：

为什么RELEASE会解析成最老版本？ #

核心原因出在Maven对RELEASE版本的解析逻辑和仓库元数据的变化上：

1. RELEASE版本的本质是依赖仓库元数据
   Maven的RELEASE版本并不是自动找最新版，而是去对应仓库（中央仓库或你们公司私有仓库）读取commons-io/commons-io/maven-metadata.xml文件，里面的<release>标签指定了哪个版本会被当作“RELEASE”版本。如果这个标签被意外改成了20030203.000550这个古老版本，所有用RELEASE的项目都会解析到它。

2. 仓库端的元数据异常
   既然全员都遇到这个问题，肯定不是本地Maven缓存的问题，大概率是你们依赖的仓库（中央仓库同步出问题，或者公司私有仓库的元数据损坏/被篡改）。比如私有仓库同步中央仓库时出错，导致元数据没有更新到最新的正确状态，甚至回滚到了旧版本的元数据。

3. commons-io版本号的历史特殊性
   早期的commons-io确实用时间戳作为版本号（比如20030203.000550），后来才改成了常规的1.x、2.x递增版本号。仓库元数据如果出问题，很容易误把最老的版本标记成RELEASE。

解决办法 #

1. 紧急修复：锁定明确版本号 #

这是最快解决问题的办法，直接把RELEASE替换成你们实际在用的版本号（比如2.11.0、2.15.0这类）。可以通过以下方式确定版本：

• 查看项目之前成功构建的日志，里面会有依赖的具体版本记录
• 检查本地Maven仓库中之前缓存的commons-io文件夹，里面的版本号就是你们之前用的

修改后的依赖配置示例：

<dependency>
    <groupId>commons-io</groupId>
    <artifactId>commons-io</artifactId>
    <version>2.15.0</version>
</dependency>

2. 排查仓库元数据 #

联系公司负责仓库运维的同事，检查：

• 公司私有仓库中commons-io的maven-metadata.xml文件，确认<release>标签是否指向正确的最新稳定版
• 如果是同步中央仓库的问题，重新触发同步，确保元数据更新到最新状态

3. 长期优化：避免使用动态版本号 #

RELEASE、LATEST这类动态版本号本身就有稳定性风险，因为依赖仓库的元数据变化不受你们控制。建议所有依赖都使用固定版本号，这样能保证项目构建的可重复性，避免这类突发问题。

内容的提问来源于stack exchange，提问作者user3690370