DUPLICATE
您好，
所以我最近看到 Groovy 发布到版本 1.6 并且在收听Java Posse播客时他们正在评论这个版本中有多少包装它应该已经 2.0 发布。
这让我思考。版本号是否随意？我曾经认为他们有意义，但我猜不是。这只是基于里程碑的，并将项目设置为项目吗？
您的团队如何控制您的版本号和版本？
提前致谢
答案 0 :(得分：7)
区分用于营销的版本控制和用于技术用途的版本控制。
对于营销，答案是：“无论您希望客户想到什么。”在这种情况下，“主要新版本”应该附带一个主要版本号。
另外请注意，细心的客户会犹豫是否使用“主要”新版本，直到时间过去，并且他们已经在测试环境中尝试过。 “构建更改”版本被视为具有错误修复和其他不需要太多安装过程的小事。
对于技术用途，答案是：“无论您想为开发人员编码什么信息。”没有一种正确的方法可以做到这一点;这取决于你的目标。
也许“主要”版本意味着“可能意味着许多新错误的重大变化”。也许每个编译都会出现一个新的“构建”数字。也许按日期每晚构建标签是您的版本。你可以根据时间，Scrum周期，里程碑，功能等来做它！
答案 1 :(得分：6)
他们非常武断。很多人喜欢像
这样的东西[major].[minor].[release].[revision]
作为他们的版本控制方案，但我也一直在拒绝发布1.0品牌产品的公司，因为其中一个副总裁不想这样做。营销也可以影响这一点。
要求增加主要版本的一个好问题可能是：
如果这是付费产品，客户是否会付费升级到这个较新的版本？
如果是这样，可能会增加主要数字。
答案 2 :(得分：5)
MajorRelease.MinorRelease.Hotfix
答案 3 :(得分：1)
版本号是任意的，但有一些规则（我认为）。非常小的变化或错误修正通常会增加0.0.1，即V1变为V1.0.1。功能的微小改变增加0.1.0，即V1.0.1变为V1.1.0。重大更改或重写会增加1.0.0，即V2。
也就是说，当类似的变化为0.1.0时，许多公司似乎试图通过上升1.0.0来说服客户。此外，一些依赖支持合同的公司将免费提供0.1.0更新，但收取1.0.0更新费用。
另外，IIRC，一些项目倾向于用奇数版本和稳定版本表示实验版本为偶数版本（因此V3很危险，V4稳定）。
答案 4 :(得分：0)
对于库，版本号会告诉您两个版本之间的兼容性级别，因此升级会有多困难。
错误修复版本需要保留二进制，源代码和序列化兼容性。
次要版本对不同的项目意味着不同的东西，但通常他们不需要保持源兼容性。
主要版本号可以打破所有三种形式。
我写了更多关于理由here。