始终使用Maven快照有什么后果？

Question

我与一个管理大量非常小的应用程序（约100个Portlet）的小团队合作。每个portlet都有自己的git存储库。在我今天审核的一些代码中，有人做了一个小编辑，然后将他们的pom.xml版本从1.88-SNAPSHOT更新为1.89-SNAPSHOT。我添加了一条评论，询问这是否真的是我们想要发布的版本，但我真的不知道这样做的负面后果。

为什么不这样做？我知道快照不应该是发布，但为什么不呢？仅使用快照会产生什么后果？我知道maven不会像非快照一样缓存快照，因此每次都可以下载工件，但让我们假装缓存并不重要。从发布管理的角度来看，为什么每次都使用SNAPSHOT版本而只是将数字误认为是一个坏主意？

更新： 这些项目中的每一个都会生成一个war文件，该文件永远不会在我们团队之外的maven repo上提供，因此没有下游用户。

Answer 1

不想这样做的主要原因是整个Maven生态系统依赖于快照版本的具体定义。而这个定义并不是您在问题中设置的定义：它只应该代表当前处于活动开发阶段的版本，并且它不应该是稳定版本。结果是，围绕Maven构建的许多工具默认采用这个定义：

1. maven-release-plugin不允许您准备快照版本为已发布版本的版本。因此，您需要在版本控制上手动标记，或者创建自己的脚本。这也意味着这些库的用户将无法使用此插件进行默认配置，他们需要设置allowTimestampedSnapshots。
2. 可用于自动更新到最新发布版本的versions-maven-plugin也无法正常运行，因此如果没有配置上的痛苦，您的用户将无法使用它。
3. 存储库管理器，如Artifactory或Nexus，内置了明确区分托管快照依赖关系和版本依赖关系的存储库。例如，如果您在公司范围内使用共享Nexus，则可以将其配置为to purge old snapshots，这样就可以为您解决问题...想象某人依赖1.88-SNAPSHOT并完全删除它：您将拥有回到过去并重新部署它，直到下次删除...此外，某些Artifactory内部存储库可以配置not to accept任何快照，因此您将无法在那里部署它;同样，用户将被强制添加更多存储库配置，以指向那些允许快照的存储库配置，这可能是他们不想做的。
4. Maven是关于配置之前的约定，这意味着所有Maven项目都应该尝试共享相同的语义（目录布局，版本控制......）。将访问您的项目的新开发人员将会感到困惑，并且会浪费时间来理解为什么您的项目按照原来的方式构建。

最后，这样做只会给用户带来更多痛苦，并且不会简化一件事。也许，你可以使它有点工作，但当某些事情要破坏时（因为公司政策或其他一些未来的变化），不要表现得很惊讶......

Answer 2

为了打破Maven的最佳实践，Tunaki给出了很多合理的观点，我完全支持这种观点。但即使你不关心“其他公司的惯例”，也有理由：

1. 如果您没有进行CI（并将每个构建视为潜在版本），则需要区分应该高效的版本和仅用于测试的版本。如果一切都是SNAPSHOT，那很难做到。

2. 如果有人（不小心）部署了第二个1.88-SNAPSHOT，它将是新的1.88-SNAPSHOT，隐藏旧的（通过具体的时间戳可用，但这很麻烦）。发布版本无法部署两次。