更新#19/18
我的公司已经决定彻底改变他们的开发/发布周期，以适应越来越多的开发人员。
git过程将类似于成功的分支模型，只做了一些更改。开发人员不需要直接推送访问"开发"分支，而是需要提出合并/拉取请求，这需要代码审查和基本单元测试。
版本系统将是Major。少数的修补程序，其中主要版本标记向后兼容性中断，次要版本标记新功能和次要错误修复，修补程序标记关键热修复。这个新版本系统将删除Jenkins构建号作为一条有用的信息，但出于历史目的，将其附加到已部署的工件上。
Jenkins将跟踪"开发"分支，以构建SNAPSHOT并将其部署到我们当地的Nexus，因此开发人员可以使用未发布但已接受的功能。Jenkins还将跟踪"master"分支，以构建和部署发布工件。
发布过程将：
- 根据发布的功能更新POM版本
- Git用新版本标记分支
- 执行单元、集成和系统测试
- 构建、混淆并将发布工件部署到我们的Nexus
- 对于新的开发SNAPSHOT，将"开发"分支版本更新为"Major.Minor++-SNAPSHOT">
原始帖子
我正在尝试构建一个模糊的JAR库，使用基于Jenkins/Hudson构建的动态构建号，并部署到内部Sonateype Nexus。
我的问题是Maven安装/部署不接受对finalName的更改，并且使用如下表达式设置版本被认为是"错误做法"：
<version>1.0.${buildNumber}</version>
尽管这是一种糟糕的做法，但它使用正确的本地和远程版本正确地安装/部署工件。内部版本号基于一对与Jenkins构建系统的内部版本号环境变量的存在相关的配置文件，如果没有该变量，则默认为0：
<profile>
<id>static_build_number</id>
<activation>
<property>
<name>!env.BUILD_NUMBER</name>
</property>
</activation>
<properties>
<buildNumber>0</buildNumber>
</properties>
</profile>
<profile>
<id>dynamic_build_number</id>
<activation>
<property>
<name>env.BUILD_NUMBER</name>
</property>
</activation>
<properties>
<buildNumber>${env.BUILD_NUMBER}</buildNumber>
</properties>
</profile>
我们不使用SNAPSHOT版本，因为任何提交并推送到Nexus的版本都被视为测试发布版本。
有没有一种"正确"的方法可以根据Jenkins/Hudson动态构建号设置Maven版本，允许它与更新的版本一起部署？
maven方式表示，只有当您发布代码时，版本才会更改，并且同一版本的两个连续构建应该产生相同的输出。
在您的情况下，您将反对这两个良好做法。
如果真的每一次提交都是一个新版本，那么你所做的听起来并不是很错误(但对我来说确实很有趣)。一个缺点是，它看起来不像是从VCS创建标签(这是另一个好的实践)。
老实说。我不敢相信每一次提交都是一次准备生产的发布。我从未见过这种情况，即使在连续交付环境中也是如此，在这种环境中，每次提交都需要通过大量的自动化测试，有时修订会被拒绝(可能是出于功能或性能原因)。