补丁的 Maven 工件版本
我目前正在研究 用于 Project Dash 的 Maven 工具。悬而未决的问题之一是如何处理错误。
Maven 中心说：发布的内容永远不会改变。这是因为 Maven 从不尝试确定版本是否已更改（与 SNAPSHOT 不同）。
但我可能必须创建一个新的“版本”，例如 Eclipse 3.6.2 的一部分。我应该使用哪个版本号？ 3.6.2.1、3.6.2-1、3.6.2_1、3.6.2pl1？为什么？
I'm currently working on Maven tools for Project Dash. One of the open issues is how to handle mistakes.
Maven central says: Nothing published ever changes. This is because Maven never tries to figure out whether a release has changed (unlike for SNAPSHOTs).
But I might have to create a new "release" of, say, part of Eclipse 3.6.2. Which version number should I use? 3.6.2.1, 3.6.2-1, 3.6.2_1, 3.6.2pl1? Why?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
版本号的约定是
major.minor.build。当公共接口发生不兼容更改时，
major会递增。例如，方法被删除，或其签名发生更改。使用您的库的客户在使用具有不同主要版本的库时需要小心，因为事情可能会崩溃。当公共接口以兼容方式更改时，
minor会递增。例如添加一个方法。客户无需担心使用新版本，因为他们习惯看到的所有功能仍然存在并且行为相同。当函数的实现发生变化时，
build会递增，但不会添加或删除签名。例如，您发现了一个错误并修复了它。客户可能应该更新到新版本，但如果由于依赖损坏的行为而无法正常工作，他们可以轻松降级。这里棘手的问题是，听起来您正在修改其他人编写和发布的代码。正如我所看到的，这里的约定是在版本号后添加
-yourname-version或仅使用 -version。例如，linux-image-2.6.28-27可能是 Ubuntu 内核映像的名称。然而，由于 Maven 使用破折号来区分工件坐标，因此我建议（显然非常啰嗦）只添加
.version以避免混淆。因此在本例中为3.6.2.1。The convention for version numbers is
major.minor.build.majoris incremented when the public interface changes incompatibly. For example, a method is removed, or its signature changes. Clients using your library need to take care when using a library with a different major version, because things may break.minoris incremented when the public interface changes in a compatible way. For example, a method is added. Clients do not need to worry about about using the new version, as all the functions they are used to seeing will still be there and act the same.buildis incremented when the implementation of a function changes, but no signatures are added or removed. For example, you found a bug and fixed it. Clients should probably update to the new version, but if it doesn't work because they depended on the broken behavior, they can easily downgrade.The tricky issue here is that it sounds like you are modifying code written and released by somebody else. The convention here, as I have seen it, is to postfix the version number with either
-yourname-versionor just -version. For example,linux-image-2.6.28-27is a likely name of a Ubuntu kernel image.As Maven uses dashes to differentiate between artifact coordinates, however, I would recommend (very long-windedly, apparently) to just add
.versionto avoid confusing it. So3.6.2.1in this case.Maven 项目版本的指定方式类似于 这个。
由于您不想更改版本号，因此您正在寻找限定符。不知道有没有通用推荐的限定符名称。 Spring人例如做了类似这样的事情
他们没有使用连字符/破折号来分隔限定符。
无论你做什么，你都必须小心版本的排序！看看我添加的第一个链接。
更新：另请参阅 @krzyk 评论以了解最近的更改/添加。
Maven project versions are specified like this.
As you do not want to change the version number you are looking for a qualifier. I do not know if there is a general recommendation for the name of the qualifier. The Spring people e.g. did something like this
They didn't use the hyphen/dash notation to seperate the qualifier.
What ever you do, you have to be careful regarding the ordering of versions! Have a look at the first link I added.
Update: Also have a look at @krzyk comment for recent changes/additions.
这不是根本原因。原因是为了将来拥有可靠的构建。您在 pom 中定义版本即可。如果有人从 Maven Central 中删除工件，或者更改现有工件而变得更糟，那么您无法确定您的构建将来是否可以工作......或者较旧的构建是否可以工作。
版本号由你决定...我建议使用 3.6.2.1。
That's in my opinion not the basic reason. The reason is to have reliable builds in the future. You define the versions in your pom and that's it. If someone would remove artifacts from maven central or become worse changing an existing artifact you can't be sure that your build will be working in the future...or an older build would work.
The version number is up to you...i would suggest to use 3.6.2.1.