何时将软件版本号从1.x增加到2.x?

时间:2011-09-15 08:52:09

标签: versioning

我知道有很多关于如何使用(甚至使用)软件版本的想法。 即使我想知道软件版本在1.x之后应该变成2.x.

在我的例子中,我使用1和2,但当然可能是任何其他数字。

是否经过完全重写?还是一个新的/大部分更新的用户界面?一堆新的(主要)功能?在将程序重写为“核心”之后?

当我看到(可能是一个不好的例子)Internet Explorer或Chrome时,我无法真正说出为什么他们如此迅速地增加了他们的“主要”版本......

我现在的想法是,当一个程序从1.x升级到2.x时,应该用至少相同的功能完全重写,只有更好(更稳定,更优化,更清晰的代码等)< / p>

有什么想法吗?

3 个答案:

答案 0 :(得分:10)

最终,我们开发的任何东西都是为某人或某物使用。当某些东西被使用,并且有能力改变时,无论是谁在使用它通常都想知道什么时候事情发生变化以及它们有多少变化,这样他们就可以为任何破坏他们如何使用它的东西做好准备。

为此,版本号的目标是快速确定两个版本之间的差异范围(在这种情况下,软件项目的两个版本)。

总结到目前为止:

  1. 我们发展的一切都会随着时间而变化
  2. 我们开发的所有东西都是其他人可以使用的
  3. 用户关注关于这些更改,因为它可能会破坏他们的东西
  4. 用户需要一种快速的方法来确定新版本是否会破坏他们的东西
  5. 要点2 - 4告诉我们,我们的软件应该有一个定义良好的外部接口(API),并且我们软件的版本控制系统应该指示外部接口何时发生变化,因为这是其他人使用的。

    Semantic Versioning项目详细说明了如何完成此操作的规范。我不会重复规范中的所有内容(实际上,它不是很长),但这里有一些要点:

    1. 版本号的格式为X.Y.Z
      • X是主要版本
      • Y是次要版本
      • Z是补丁版本
    2. 修补程序版本(Z)针对向后兼容的错误修复
    3. 递增
    4. 次要版本(Y)会增加新的,向后兼容的功能会将引入API
    5. 主要版本(X)会针对向后不兼容的更改而增加
    6. 规范中还有一些细节,以及其他理由和理由,但这些都是要点。

      最后,所有版本号都提供了一种结构化的方式来指示对使用该软件的其他实体的更改。只要您满足他们的需求且一致,任何版本控制方案都可以。

答案 1 :(得分:3)

通常情况下,此类版本更改会表明功能发生重大变化。

我倾向于使用的经验法则是:

1.0 - 2.0(主要变化,大量额外或修改的功能)
1.0 - 1.1(微小变化,一些额外或修改的功能)
1.0 - 1.0.1(错误修复或其他小补丁,核心功能没有变化)

http://en.wikipedia.org/wiki/Software_versioning

列出了几种不同的方案

答案 2 :(得分:2)

这完全取决于你,真的。

一些软件,比如OpenSSL在经过多年的开发后才达到1.0,而FireFox和IE等浏览器软件似乎经常发布主要版本。

这是一个品味问题。