我有一个web应用程序，我们会在每次功能准备好时部署到生产环境，有时一天可能会进行几次，有时发布之间可能会有几周时间。
目前，我们的项目没有增加版本号，一切都已经停留在版本号 0.0.1-SNAPSHOT超过一年了。我想知道Maven在web应用程序中进行持续交付的方式是什么。对于每个提交都增加版本号似乎有些过度，而像我们现在做的那样从不增加版本号也似乎是错误的。
这种Maven使用的推荐最佳实践是什么？
实际上，问题分为两个方面：
pom.xml文件中提升项目版本号（可能会有很多）。根据Mark O'Connor的回答中链接的视频，该解决方案需要像git这样的DVCS和像Jenkins这样的CI服务器。
1.0-SNAPSHOT之类的快照版本将变成真实版本，例如1.0.buildNumber，其中buildNumber是Jenkins作业编号。算法步骤：
1.0-SNAPSHOT1.0.JENKINS-JOB-NUMBER的git分支，以便将快照版本转换为真实版本1.0.1241.0-SNAPSHOT更改为1.0.JENKINS-JOB-NUMBERmvn install mvn install 成功，则Jenkins将提交分支 1.0.JENKINS-JOB-NUMBER ，并创建一个带有适当标记的真实非快照版本以便以后复现。 如果 mvn install 失败，则Jenkins将仅删除新创建的分支并使构建失败。
我强烈建议观看Mark回答中链接的视频。
从Maven 3.2.1开始，内置支持连续交付友好版本：https://issues.apache.org/jira/browse/MNG-5576 您可以在版本中使用3个预定义变量：
${changelist}
${revision}
${sha1}
所以你基本上要做的是：
1.0.0-${revision}。（你可以使用 mvn versions:set 在多模块项目中快速且正确地执行此操作。）<revision>SNAPSHOT</revision>。mvn clean install -Drevision=${BUILD_NUMBER} 或类似的命令，甚至可以是 mvn clean verify -Drevision=${BUILD_NUMBER}。你可以使用例如https://wiki.jenkins-ci.org/display/JENKINS/Version+Number+Plugin来生成有趣的构建编号。
一旦你发现构建稳定（例如通过验收测试），你就可以将版本推送到 Nexus 或其他仓库。任何不稳定的构建都将被删除。
<version>1.0${revision}</version>，并使用属性<revision>-SNAPSHOT</revision>，然后在CI构建期间使用mvn clean deploy -Drevision=".$TRAVIS_BUILD_ID"。它会产生_补丁_版本，这些版本是_不寻常的_，但始终在增加，因此它们符合semver... - Lucas有一些关于如何处理Maven版本号和持续交付（CD）的好的讨论和建议（我会在我的回答后添加它们）。
首先，我对SNAPSHOT版本的看法。在Maven中，SNAPSHOT表示该版本目前正在开发中，是特定版本的SNAPSHOT后缀之前的版本。因此，像Nexus或maven-release-plugin这样的工具对SNAPSHOT有特殊处理。对于Nexus，它们存储在单独的存储库中，并且允许使用相同的SNAPSHOT发布版本更新多个构件。因此，在项目中不建议使用SNAPSHOT依赖项，尤其是在CD世界中，因为构建不再可靠。
SNAPSHOT作为项目版本将成为问题，当其他项目使用您的项目时，就会出现上述问题。
对我来说，SNAPSHOT的另一个问题是它不太可追踪或可重现。当我在生产环境中看到版本0.0.1-SNAPSHOT时，我需要进行一些搜索，以找出它是从哪个修订版本构建的。当我在文件系统上找到这个软件的版本时，我需要查看pom.properties或MANIFEST文件，以确定这是否为旧垃圾还是最新版本。
为了避免手动更改版本号（特别是当您每天构建多个构建时），让构建服务器为您更改编号。因此，对于开发，我会选择一个
<major>.<minor>-SNAPSHOT
版本号通常以SNAPSHOT结尾，但在构建新版本时，构建服务器可以将SNAPSHOT替换为更独特和可追踪的内容。
例如：
<major>.<minor>-b<buildNumber>
<major>.<minor>-r<scmNumber>
<year>.<month>.<day>.<buildNumber>
以下是缺失的链接：
不要这样做！
<Major>.<minor>-<build>
会咬你一口的是Maven会将连字符后面的任何内容视为词汇上的，这意味着版本1在词法上比版本10高。
如果你正在向Maven请求最新版本的某个东西，那么上述问题就会出现。
解决方法是在构建号之前使用小数点代替连字符。
请务必这样做！
<Major>.<minor>.<build>
在本地使用SNAPSHOT版本是可以的，但在构建过程中最好使用正式版本。
mvn versions:set -DnewVersion=${major}.${minor}.${build.number}
在我们的网页应用程序中，我们目前使用以下版本控制模式：
<jenkins build num>-<git-short-hash>
例如：247-262e37b9。
这种模式的好处在于它可以给你一个始终独一无二并且可追溯到产生它的Jenkins构建和Git修订的版本。
在 Maven 3.2.1+ 中，他们终于杀死了使用 ${property} 作为版本的警告，因此这使得构建变得非常容易。只需要将所有的 poms 更改为使用 <version>${revision}</version> 并使用 -Drevision=whatever 进行构建即可。唯一的问题是，在您发布的 poms 中，实际的 pom 文件中版本仍将保持为 ${revision}，这可能会导致各种奇怪的问题。为解决此问题，我编写了一个简单的 Maven 插件（https://github.com/jeffskj/cd-versions-maven-plugin），该插件在文件中进行变量替换。
pom.xml文件版本本身的解决方案。然而，下一个问题是更新所有参与发布的依赖组件中的版本，以便它们实际上使用彼此的最新版本。在多模块/反应堆构建中（更新外部和不仅限于内部组件），我遇到了**自动更新不可靠的问题。因此，短期解决方案是保持SHAPSHOT。您对如何解决这个问题有什么评论吗？** - uvsmtid${project.version}。然后简单地运行mvn versions:set -DnewVersion=whatever就可以改变反应堆顺序中包括父级在内的版本。 - Piotr Gwiazda