Maven 和快照？
我正在开发一个快速项目，其中，我直接开发一个不断变化的模块。其他人直接依赖于该模块，因此，我删除了公共接口并将其作为 0.0-SNAPSHOT 部署到我们的本地 Nexus 存储库中以供使用。
现在我几乎完成了模块的第一次迭代，我尝试重新部署更新的工件。在阅读有关快照的内容时，其他人声称快照应该代表当前的头部躯干。这是真的吗？
Maven 在重新部署时自动增加我的快照版本 - 因此，从 0.0-SNAPSHOT 开始，我仍然处于 0.0-SNAPSHOT，只是，它是相同版本的迭代 3 或 4快照。我什么时候应该过渡到 0.1-SNAPSHOT？是否有一个插件可以用来自动更改版本，而不是手动编辑我的 pom？
在集成测试和部署我们的第一个系统版本 1.0-RELEASE 后，我的模块应该如何进展？我应该将模块移至 1.0-SNAPSHOT 并继续吗？是否有一种应该遵循的方法，或者是否由开发人员自行决定？
I'm working on a rapid project, of which, I'm directly working on a module that is continuously changing. Others have a direct dependency on the module, and as such, I stubbed out the public interface and deployed it to our local Nexus repository as 0.0-SNAPSHOT for use.
Now that I've almost completed my first iteration of the module, I've attempted to redeploy the updated artifact. Reading about snapshots, others claim that a snapshot should represent the current head trunk. Is this true?
Maven automatically increments my snapshot version upon redeploy - so, going from 0.0-SNAPSHOT, I'm still at 0.0-SNAPSHOT, only, it's iteration 3 or 4 of the same snapshot. When should I roll over to 0.1-SNAPSHOT? Is there a plugin I can use to automate the version change, instead of manually editing my pom?
After integration testing and the deployment of our first system release, 1.0-RELEASE, how should my module progress? Should I move my module to 1.0-SNAPSHOT and continue thereon? Is there a methodology one should follow, or is it left to the discretion of the developer?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
XYZ-SNAPSHOT 表示法标识了发布 XYZ 之前的临时版本，因此您通常不会从 XYZ-SNAPSHOT 移动到 XYZ+1-SNAPSHOT，除非您发布 XYZ 如果您遵守此约定，则 maven-release-plugin 可以帮助您完成完整的发布过程。
请注意，最常见的 Maven 约定使用不带任何后缀的 3 位数版本标识符（即无 -RELEASE）。后缀通常用于区分同一版本的变体。
Maven 是关于约定的，所以如果不阅读它，您就不可能走得太远：这个
The X.Y.Z-SNAPSHOT notation identifies temporary versions leading up to release X.Y.Z, so you usually do not move from X.Y.Z-SNAPSHOT to X.Y.Z+1-SNAPSHOT unless you release X.Y.Z. If you adhere to this convention the maven-release-plugin may help you with the full release process.
Note that the most common Maven convention uses 3-number release identifiers without any suffix (i.e. no -RELEASE). Suffixes are usually used to distinguish variants of the same release.
Maven is all about conventions, so there's little chance you'll go very far without reading about it: This book is a good starting point.
要更新 POM 版本而不手动更新，您可以查看 Maven Release 插件 （虽然我自己写了一个小脚本来进行 POM 更新，因为我发现 Release 插件不太适合我的工作流程）
然后就涉及到你的版本号问题。这更多的是一个发布程序问题。通常，计划发布由版本号中主要或次要版本的增量表示。 SNAPSHOT 版本表示某个版本正在进行中。例如，我更愿意为您的情况做这样的事情：
假设我计划将第一次迭代发布为 0.1，那么我将在 SCM 中制作我的头主干（例如 SVN 中的主干），并使用 0.1-SNAPSHOT 作为版本。这表明所有开发实际上都在为 0.1 版本的发布做出贡献。完成后，我会将 POM 版本从 0.1-SNAPSHOT 更新到 0.1，执行版本 0.1 的实际发布（包括发布分支、标记、部署工件），然后将 POM 版本更改为下一个计划发布的 SNAPSHOT（对于例如，0.2-SNAPSHOT）。
同样，在发布 1.0（或示例中的 1.0-RELEASE）后，head trunk 中的 POM 版本应更新为下一个发布版本的快照，例如 1.1-SNAPSHOT。
请记住，如果某个版本确实已发布，则不应再有该版本的快照。
For updating your POM version without manually updating, you may take a look at Maven Release plugin (Although I wrote myself a little script to do the POM update as I find Release plugin don't fit that good in my work flow)
It then come to your version number issue. It is more a release procedure issue. Normally a planned release is denoted by increment of Major or Minor version in the version number. SNAPSHOT version denote that certain release is in progress. For example, I will prefer doing something like this for your case:
Assume I am planning to release first iteration as 0.1, then I will make my head trunk in SCM (e.g. trunk in SVN) with 0.1-SNAPSHOT as version. Which denotes that all development is in fact contributing to release of version 0.1. Upon finish, I'll update the POM version from 0.1-SNAPSHOT to 0.1, perform an actual release of version 0.1 (including release branching, tagging, deploying the artifact), and then change the POM version to SNAPSHOT of next planned release (for example, 0.2-SNAPSHOT).
Similarly, after releasing 1.0 (or 1.0-RELEASE in your example), POM version in head trunk should then be updated to snapshot of your next release version, for example, 1.1-SNAPSHOT.
Just bear in mind that there should no longer be SNAPSHOTs of certain version, if that version is actually released.
了解 maven 解释 SNAPSHOTS 的方式可以消除您可能存在的任何疑问。
摘自 http://books.sonatype.com /mvnref-book/reference/pom-relationships-sect-pom-syntax.html
首先，我建议坚持 Maven 约定并将您的版本更改为
0.1作为maven archetype:generate的建议。因此，
SNAPSHOT可帮助其他人轻松了解您的活动项目的最新情况。在每次编译时，他们的项目都会检查SNAPSHOTS依赖项的新版本（基于其.m2目录中的伪日期时间版本）。完成
0.1-SNAPSHOT上的工作后，您可以部署0.1并启动0.2-SNAPSHOT或1.0-SNAPSHOTUnderstand the way maven interprets SNAPSHOTS is to clear any doubt you can have.
Extract from http://books.sonatype.com/mvnref-book/reference/pom-relationships-sect-pom-syntax.html
First, Let me suggest to stick on maven conventions and change your version to
0.1asmaven archetype:generatepropose.So
SNAPSHOThelps others to stay up-to-date easily with your active project. On every compilation, their projects will check new releases ofSNAPSHOTSdependencies (based on that pseudo-datetime-version they have on its.m2directory).When you finish work on
0.1-SNAPSHOTyou deploy an0.1and start a0.2-SNAPSHOTor1.0-SNAPSHOT