如何命名后续将合并为正式版本的多个SNAPSHOT版本？

我们团队使用Nexus仓库存储从develop分支构建的JAR文件，用于测试及准备发布SNAPSHOT版本。

仓库分支结构 #

• main：单分支，仅用于存放生产代码
• develop：单分支，用于存放预发布代码，测试后合并至main
• feature_xyz：多个从develop分支创建的特性分支，完成开发后合并回develop

场景示例 #

假设某Maven项目已发布2.5.0版本，我们分别从develop分支创建feature_foo和feature_bar特性分支，并将版本改为2.5.1-SNAPSHOT。我们希望先在本地测试不稳定的代码，避免同事拉取到。

当前痛点 #

本地运行代码需要依赖该Maven项目的2.5.1-SNAPSHOT版本JAR，但该JAR只能从develop分支构建后推送到Nexus仓库。这就导致我们为了本地测试，不得不把未经过本地验证的SNAPSHOT版本推到develop，同事可能会拉取到这些不稳定的代码。其他同事开发2.5.1-SNAPSHOT版本时也会遇到同样的问题。我们的核心目标是：让每位开发者仅能获取包含自己开发特性的SNAPSHOT版本JAR文件。

初步设想 #

讨论后打算把SNAPSHOT版本命名为2.5.1-SNAPSHOT-1、2.5.1-SNAPSHOT-2这类格式，推送到Nexus后各自本地使用，等测试完成后，再把feature_foo和feature_bar分支合并至develop，统一使用2.5.1-SNAPSHOT版本。

想请教：是否有更优的方案？如果我们这个方案可行，有没有对应的命名规范可以遵循？

一、更优方案：使用Maven「分类器（Classifier）」特性 #

你的初步思路方向是对的，但直接修改SNAPSHOT版本号会破坏Maven的版本规范，更合理的做法是利用Maven的分类器来区分不同特性分支的构建产物。

具体操作 #

1. 特性分支开发时，保持版本号为2.5.1-SNAPSHOT不变，构建时添加自定义分类器（建议用特性分支名或开发者ID）：

   • 构建命令示例：mvn clean deploy -Dclassifier=feature-foo
   • 构建后生成的JAR文件名为：artifact-id-2.5.1-SNAPSHOT-feature-foo.jar

2. 本地依赖时，在pom.xml中指定分类器：

   <dependency>
       <groupId>your-group-id</groupId>
       <artifactId>your-artifact-id</artifactId>
       <version>2.5.1-SNAPSHOT</version>
       <classifier>feature-foo</classifier>
   </dependency>
   

3. 特性分支测试完成合并到develop后，直接构建不带分类器的2.5.1-SNAPSHOT版本推送到Nexus，所有开发者切换依赖到无分类器的版本即可。

优势 #

• 严格遵循Maven版本规范，不会出现自定义版本号导致的依赖解析问题
• 分类器清晰关联特性分支，便于识别和管理
• 无需修改项目版本号，减少分支合并时的版本冲突

二、自定义版本号方案的命名规范（若坚持使用） #

如果你们更倾向于修改版本号的方式，建议遵循以下规范避免混乱：

• 格式：主版本.次版本.修订版本-SNAPSHOT-<标识>
  • 示例：2.5.1-SNAPSHOT-feature-foo、2.5.1-SNAPSHOT-john-doe（用开发者ID也可）
• 标识部分建议使用小写字母、连字符，避免特殊字符，确保Maven能正常解析
• 合并到develop后，统一回退为2.5.1-SNAPSHOT，并删除Nexus中所有带后缀的SNAPSHOT版本

三、额外建议：Nexus权限辅助配置 #

可以在Nexus中为每个开发者或特性分支配置独立的快照仓库，或者设置权限让开发者只能拉取自己推送的快照版本。不过这种方式配置成本较高，不如分类器方案轻便。

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