总结：生产环境Release、Snapshot两种包版本该如何管理与发布构建

总结：生产环境release、snapshot两种包版本该如何管理与发布构建

一·Release、Snapshot两种包该如何分别管理与发布构建呢？
- [1. 核心开关：版本号命名](#1. 核心开关：版本号命名)
- [2. 如何发布构建 (Deploy)](#2. 如何发布构建 (Deploy))
- [3. 如何管理依赖拉取 (Dependency)](#3. 如何管理依赖拉取 (Dependency))
- [4. 推荐的规范化研发流程（最佳实践）](#4. 推荐的规范化研发流程（最佳实践）)

一·Release、Snapshot两种包该如何分别管理与发布构建呢？

在 Maven 中，Release（正式版）和 Snapshot（快照/开发版）的管理与发布，核心完全依赖于版本号（）的命名规范，Maven 底层会根据版本号的后缀自动进行路由和策略处理。

具体来说，你可以通过以下几个方面来分别管理和发布这两种包：

1. 核心开关：版本号命名

Maven 识别包类型的唯一标准是：版本号是否以 -SNAPSHOT（必须全部大写）结尾。

Snapshot 版本：例如 1.0.0-SNAPSHOT。代表这是一个处于开发中、不稳定的版本。

Release 版本：例如 1.0.0 或 1.0.0-RELEASE。只要不带 -SNAPSHOT，Maven 均视其为稳定的正式版。

2. 如何发布构建 (Deploy)

当你执行 mvn deploy 命令进行构建并推送到私服时，你不需要手动指定推送到哪个仓库，Maven 会自动根据版本号判断：

（1）发布 Snapshot： 当前版本号带有 -SNAPSHOT，Maven 会自动找到下的配置，将其上传到 libs-snapshots-local 仓库。由于是快照，私服会自动在原包名后追加时间戳（如 1.0.0-20231010.1230），允许多次覆盖发布。

（2）发布 Release： 当前版本号剔除了 -SNAPSHOT，Maven 会自动找到下的配置，将其上传到 libs-releases-local 仓库。注意：Release 仓库通常具备只读属性，同版本号的 Release 包一旦发布，就严禁再次覆盖上传。

xml 复制代码

//项目发布/上传配置
<distributionManagement>
        <repository>
            <id>libs-releases</id>
            <url>
                http://xxx/xxx
            </url>
        </repository>
        <snapshotRepository>
            <id>libs-snapshots</id>
            <name>xxx repository-snapshots</name>
            <url>http://xxx/xxx</url>
        </snapshotRepository>
    </distributionManagement>

//依赖库下载源配置
    <repositories>
        <repository>
            <snapshots>
                <enabled>true</enabled>
            </snapshots>
            <id>xxx-central</id>
            <name>libs-releases</name>
            <url>http://xxx/xxx</url>
        </repository>

        <repository>
            <snapshots />
            <id>snapshots</id>
            <name>libs-snapshots</name>
            <url>http://xxx/xxx</url>
        </repository>
    </repositories>

3. 如何管理依赖拉取 (Dependency)

当你的其他项目需要引入这两个包时，Maven 的本地缓存机制对这两种包采取了截然不同的管理策略：

（1）管理 Release 包： 一旦本地 Maven 仓库（.m2 目录）下载了 1.0.0 版本的 Release 包，就永远不会再去远程仓库检查更新了。这保证了生产环境依赖的绝对稳定性。
（2）管理 Snapshot 包： 如果你依赖了 1.0.0-SNAPSHOT，Maven 知道这个版本会频繁更新。默认情况下，Maven 每天会去私服检查一次有没有最新的时间戳快照；如果你急需拉取同事刚推上去的代码，可以在执行构建命令时加上 -U 参数（例如 mvn clean compile -U），强制 Maven 立即去私服拉取最新的 Snapshot 覆盖本地代码。

4. 推荐的规范化研发流程（最佳实践）

在实际的企业级项目迭代中，我们通常这样配合使用：
日常开发阶段： 大家都在特性分支开发，把版本号改为 1.0.0-SNAPSHOT，随时可以 mvn deploy，团队成员通过快照频繁互相同步最新的 API 和代码。

发版/上线阶段： 准备上线前，修改 pom.xml，将版本号去掉 -SNAPSHOT，改为 1.0.0。提交代码，并在 Git 上打一个 v1.0.0 的 Tag。通过 CI/CD 流水线执行打包，将这个稳定的代码 deploy 到 Release 仓库供线上服务使用。

发版完成后： 立马修改 pom.xml，将版本号升级为下一个版本的快照，例如 1.0.1-SNAPSHOT，为下一个迭代做准备。

(注：如果你觉得手动改版本号太麻烦，业界通常会使用 versions-maven-plugin 插件的 mvn versions:set -DnewVersion=xxx 命令，或者配合 CI/CD 平台的脚本来自动修改与发布。)