为了澄清这个问题：
在某些情况下：我们的项目每周部署到集成和 QA，目前我们为每个集成部署创建一个新版本，但这感觉不对。它导致每周更新所有 pom，破坏开发级别的依赖关系，迫使每个开发人员刷新他们的 eclipse 配置。我们有很大的工作空间，而 Eclipse 不能很好地处理刷新，因此浪费了很多时间。
我对 maven 发布约定并不太熟悉，并且在应该使用 mvn release 时找不到关于应用程序生命周期点的约定。
如果我们现在使用的模式被接受/正确/建立，我会有另一个问题:)
我用来避免 Eclipse 开发级别依赖项更新问题的方法是保持相关的主干或分支版本号不变，直到版本变得重要为止。通过这种方式，您可以对 QA 等进行正确标记/版本化的发布，以便您可以追溯问题，但不需要开发人员更新依赖项。为此，我使用以下命令，但覆盖版本号以获取所需的版本号，但重新输入当前快照版本作为新快照版本：
mvn release:prepare -DautoVersionSubmodules=true
PS我有一个图表可以证明这一点，但不幸的是，这个论坛没有足够的权利来附上它。如果有人可以方便附加，我会很乐意提供它。
PPS 也许现在...
还要注意对早期分支 (2.1) 和晚期分支 (2.2) 的支持。
在我们的商店中，我们在 SVN 中的所有 POM 都有<version>9999-SNAPSHOT</version>（对于他们自己的版本以及内部依赖项）。这永远不会改变。
在构建期间，我们有一个简单的 ant build.xml，它将版本号（在 maven 之外建立）作为-Dversion=...参数，并且简单地执行以下操作：
<replace includes="**/pom.xml" token="9999-SNAPSHOT" value="${version}"/>
<artifact:mvn ... />
该更改在构建过程的工作副本中是本地的——它从未签入到版本控制中。
这样，所有发布版本都有一个“真实的”版本号，但开发人员实际上不必处理版本号。
正如您在问题中所说，上述内容强调不是执行此操作的正确方法，但自从我们采用 maven 以来，它在 ~9 mos 对我们来说效果很好。我们有数十个 Maven 模块，所有这些模块都在 QA/发布过程中步调一致。
这种方法的一个含义是，您需要为您正在处理的每个分支提供单独的 Eclipse 工作区，否则来自不同分支的项目副本将发生冲突。
[不是一个真正的答案，但我有最好的......]
与MNG-624相关。
根据您拥有的项目数量，甚至源代码控制系统的负担也可能成为问题。
有没有人使用带有 Maven 快照的独立编号方案来避免版本号搅动？ 理论上，你可以做你在没有 Maven 的情况下会做的事情——使用某种内部编号系统来进行每周构建。构建将按照工作流程的要求部署到不同的存储库；您将需要单独的存储库用于开发、质量检查，可能需要介于两者之间的用于集成测试的存储库。当您准备发布候选版本时，请开始使用非快照版本。不过，我只是在评估 Maven -我没有这样做的经验。
一些 Nexus 文档（对于专业版）讨论了如何进行构建分段，这可能是相关的。
过去我使用自己设计的编号方案：http ://wiki.secondlife.com/wiki/Codeticket_Service
我现在处于需要再次考虑 maven 的情况，我很想重新使用 codeticket 方案来生成版本号/内部版本号并通过发布插件应用它们，但不重新检查 pom 文件. 签入的 pom 文件将保留 SNAPSHOT 版本号。
对于那些关心可重现构建的人，您可以在构建结果中包含修改后的 POM 文件。就个人而言，我更关心跟踪构建工件并确保已测试的完全相同的位最终被释放，所以我对复制构建的担忧比大多数人稍微不那么虔诚（见这里）。
maven 用户列表（我参与其中）中正在进行一个似乎相关的讨论。基本上，我们正在讨论如何避免在剪切（发布或功能）分支时必须进行的所有 POM 编辑。当您创建发布分支时，发布插件可以为您进行编辑，但它对稍后需要重新集成的功能分支没有帮助。此外，当您进行合并时，所有 POM 编辑都会导致不必要的痛苦，无论是从主干重新合并合并还是重新集成合并到主干。
那里讨论的想法是基于这样一个概念，即记录工件版本号的正确位置是在 SCM 工具中，而不是在 POM 中。基本上，maven 应该能够从与工作区域关联的实际 SCM 标签或分支中导出工件版本号。
请注意，由于 Maven 的问题跟踪器（例如MNG-2971）上仍有一些问题仍未解决，因此还没有完整的解决方案。但它们已经是很多选票的问题，我很乐观，它们很快就会得到解决。