使用什么版本编号方案? [英] What version numbering scheme to use?

问题描述

我正在寻找一种版本编号方案，以表示更改的程度，尤其是兼容性.

I'm looking for a version numbering scheme that expresses the extent of change, especially compatiblity.

Apache APR 使用众所周知的版本编号方案

Apache APR, for example, use the well known version numbering scheme

<major>.<minor>.<patch>
example: 4.5.11

Maven建议使用类似但更详细的模式:

Maven suggests a similar but more detailed schema:

<major>.<minor>.<patch>-<qualifier>-<build number>
example: 4.5.11-RC1-3732

Maven版本控制方案在哪里定义?是否有关于限定符和内部版本号的约定?使用maven而不遵循Maven版本方案可能是个坏主意...

Where is the Maven versioning scheme defined? Are there conventions for qualifier and build number? Probably it is a bad idea to use maven but not to follow the Maven version scheme ...

您还知道其他哪些版本编号方案?您想要哪种方案，为什么?

What other version numbering schemes do you know? What scheme would you prefer and why?

推荐答案

这是

Here is the current Maven version comparison algorithm, and a discussion of it. As long as versions only grow, and all fields except the build number are updated manually, you're good. Qualifiers work like this: if one is a prefix of the other, longer is older. Otherwise they are compared alphabetically. Use them for pre-releases.

第二次使用语义版本控制来表达兼容性； major用于非向后兼容更改，minor用于向后兼容功能，补丁用于向后兼容错误修复.对其进行记录，以便您的库用户可以正确表达对库的依赖关系.您的快照是自动的，不需要增加这些快照，但由于比较前缀的方式，发行后的第一个快照除外.

Seconding the use of semantic versioning for expressing compatibility; major is for non-backwards compatible changes, minor for backward-compatible features, patch for backward-compatible bugfixes. Document it so your library users can express dependencies on your library correctly. Your snapshots are automated and don't have to increment these, except the first snapshot after a release because of the way prefixes are compared.

这篇关于使用什么版本编号方案?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！