java项目如何交付_java-在进行连续交付时，自动项目版本的Maven方法是什么？

关于如何处理Maven版本号和持续交付(CD)，存在一些很棒的讨论和建议(我将在答案的一部分之后添加它们)。

所以首先我对SNAPSHOT版本的看法。 在Maven中，SNAPSHOT显示当前正在开发到SNAPSHOT后缀之前的特定版本。 因此，诸如Nexus或maven-release-plugin之类的工具对SNAPSHOTS具有特殊待遇。 对于Nexus，它们存储在单独的存储库中，并且可以使用相同的SNAPSHOT版本更新多个工件。 因此，SNAPSHOT可能会在您不知道的情况下发生更改(因为您从不增加pom中的任何数字)。 因此，我不建议在项目中尤其是CD世界中使用SNAPSHOT依赖项，因为构建不再可靠。

由于上述原因，当您的项目被其他项目使用时，将SNAPSHOT作为项目版本会出现问题。

对我而言，SNAPSHOT的另一个问题是，它不再是真正可追溯或可重复的。 当我在生产中看到版本0.0.1-SNAPSHOT时，我需要进行一些搜索以找出它是从哪个版本构建的。 当我在文件系统上找到该软件的发行版时，我需要查看pom.properties或MANIFEST文件，以查看这是旧版垃圾还是最新，最好的版本。

为了避免手动更改版本号(尤其是当您每天构建多个版本时)，请让构建服务器为您更改版本号。 因此，为了发展，我会选择

.-SNAPSHOT

版本，但在构建新版本时，构建服务器可以用更独特且可追溯的方式替换SNAPSHOT。

例如以下之一：

.-b

.-r

因此，主要编号和次要编号可用于营销问题，或仅表明达到了一个新的里程碑，并且可以在需要时手动进行更改。 而buildNumber(来自Continuous Integration服务器的编号)或scmNumber(SUbversion或GIT的修订版)使每个发行版都是唯一且可追溯的。 使用buildNumber或Subversion修订版时，项目版本甚至可以排序(不带有GIT编号)。 使用buildNumber或scmNumber也可以很容易地看到此版本中的更改。

另一个示例是stackoverflow的版本控制，该版本使用

...

这里缺少链接：

管道中的版本控制

持续交付和Maven