一直使用 Maven Snapshots 的后果是什么？
What are the consequences of always using Maven Snapshots?
我与一个管理大量非常小的应用程序（约 100 个 Portlet）的小团队一起工作。每个 portlet 都有自己的 git 存储库。在我今天审查的一些代码中，有人做了一个小的编辑，然后将他们的 pom.xml 版本从 1.88-SNAPSHOT 更新到 1.89-SNAPSHOT。我添加了一条评论，询问这是否是发布版本的最佳方式，但我真的不知道这样做的负面后果。
为什么不这样做呢？我知道快照不应该是发行版，但为什么不呢？只使用快照会有什么后果？我知道 Maven 不会像非快照一样缓存快照，因此它可能每次都下载工件，但让我们假装缓存无关紧要。从发布管理的角度来看，为什么每次都使用 SNAPSHOT 版本并只是增加数量不是一个好主意？
更新：
这些项目中的每一个都会产生一个 war 文件，该文件在我们团队之外的 Maven 存储库中永远不可用，因此没有下游用户。
不想这样做的主要原因是整个 Maven 生态系统依赖于快照版本的特定定义。而且这个定义不是您在问题中设置的定义：它只应该代表当前正在积极开发中的版本，而不应该是稳定版本。结果是许多围绕 Maven 构建的工具默认采用此定义：
-
maven-release-plugin will not let you prepare a release with a snapshot version as released version. So you'll need to resort to tagging by hand on your version control, or make your own scripts. This also means that the users of those libraries won't be able to use this plugin with default configuration, they'll need to set allowTimestampedSnapshots.
- 可用于自动更新到最新发布版本的
versions-maven-plugin 也无法正常工作，因此您的用户将无法在没有配置痛苦的情况下使用它。
- 存储库管理器，如 Artifactory 或 Nexus，内置了对托管快照依赖项和发布依赖项的存储库的明确区分。例如，如果您在公司范围内使用共享 Nexus，它可以配置 to purge old snapshots so this would break things for you... Imagine someone depends on
1.88-SNAPSHOT and it is completely removed: you'll have to go back in time and redeploy it, until the next removal... Also, certain Artifactory internal repositories can be configured not to accept 任何快照，因此您将无法在那里部署它；用户将再次被迫添加更多存储库配置以指向允许快照的存储库配置，而他们可能不想这样做。
- Maven 是关于配置之前的约定，这意味着所有 Maven 项目都应该尝试共享相同的语义（目录布局、版本控制...）。访问您的项目的新开发人员会感到困惑，并且会浪费时间试图理解为什么您的项目是这样构建的。
到头来，这样做只会给用户带来更多的痛苦，并不会为你简化一件事情。也许，你可以让它有点工作，但当事情要坏了（因为公司政策，或其他一些未来的变化）时，不要表现得惊讶......
Tunaki 给出了很多您违反 Maven 最佳实践的合理观点，我完全支持该观点。但即使你不关心"conventions of other companies"，也有理由：
如果您不做 CI（并将每个构建都视为潜在版本），则需要区分应该投入生产的版本和仅用于测试的版本。如果一切都是快照，这很难做到。
如果有人（不小心）部署了第二个 1.88-SNAPSHOT，它将是新的 1.88-SNAPSHOT，隐藏旧的（可通过具体时间戳获得，但这很混乱）。发布版本不能部署两次。
我与一个管理大量非常小的应用程序（约 100 个 Portlet）的小团队一起工作。每个 portlet 都有自己的 git 存储库。在我今天审查的一些代码中，有人做了一个小的编辑，然后将他们的 pom.xml 版本从 1.88-SNAPSHOT 更新到 1.89-SNAPSHOT。我添加了一条评论，询问这是否是发布版本的最佳方式，但我真的不知道这样做的负面后果。
为什么不这样做呢？我知道快照不应该是发行版，但为什么不呢？只使用快照会有什么后果？我知道 Maven 不会像非快照一样缓存快照，因此它可能每次都下载工件，但让我们假装缓存无关紧要。从发布管理的角度来看，为什么每次都使用 SNAPSHOT 版本并只是增加数量不是一个好主意？
更新： 这些项目中的每一个都会产生一个 war 文件，该文件在我们团队之外的 Maven 存储库中永远不可用，因此没有下游用户。
不想这样做的主要原因是整个 Maven 生态系统依赖于快照版本的特定定义。而且这个定义不是您在问题中设置的定义：它只应该代表当前正在积极开发中的版本，而不应该是稳定版本。结果是许多围绕 Maven 构建的工具默认采用此定义：
-
maven-release-pluginwill not let you prepare a release with a snapshot version as released version. So you'll need to resort to tagging by hand on your version control, or make your own scripts. This also means that the users of those libraries won't be able to use this plugin with default configuration, they'll need to setallowTimestampedSnapshots. - 可用于自动更新到最新发布版本的
versions-maven-plugin也无法正常工作，因此您的用户将无法在没有配置痛苦的情况下使用它。 - 存储库管理器，如 Artifactory 或 Nexus，内置了对托管快照依赖项和发布依赖项的存储库的明确区分。例如，如果您在公司范围内使用共享 Nexus，它可以配置 to purge old snapshots so this would break things for you... Imagine someone depends on
1.88-SNAPSHOTand it is completely removed: you'll have to go back in time and redeploy it, until the next removal... Also, certain Artifactory internal repositories can be configured not to accept 任何快照，因此您将无法在那里部署它；用户将再次被迫添加更多存储库配置以指向允许快照的存储库配置，而他们可能不想这样做。 - Maven 是关于配置之前的约定，这意味着所有 Maven 项目都应该尝试共享相同的语义（目录布局、版本控制...）。访问您的项目的新开发人员会感到困惑，并且会浪费时间试图理解为什么您的项目是这样构建的。
到头来，这样做只会给用户带来更多的痛苦，并不会为你简化一件事情。也许，你可以让它有点工作，但当事情要坏了（因为公司政策，或其他一些未来的变化）时，不要表现得惊讶......
Tunaki 给出了很多您违反 Maven 最佳实践的合理观点，我完全支持该观点。但即使你不关心"conventions of other companies"，也有理由：
如果您不做 CI（并将每个构建都视为潜在版本），则需要区分应该投入生产的版本和仅用于测试的版本。如果一切都是快照，这很难做到。
如果有人（不小心）部署了第二个 1.88-SNAPSHOT，它将是新的 1.88-SNAPSHOT，隐藏旧的（可通过具体时间戳获得，但这很混乱）。发布版本不能部署两次。