最佳实践:软件版本控制

是否有什么指导方针或标准的最佳实践，如何在业余时间开发一个有趣的软件，但仍然会被一些人使用?我认为有必要对这样的软件进行版本化，这样你就可以知道第一版所谈论的内容(例如修复错误、支持等等)。

但是我从哪里开始版本控制呢?0.0.0吗?还是0.0 ?然后如何增加这些数字呢?主要版本。小改变?任何版本控制系统都不应该是另一个版本吗?或者这仅仅是用于生产方式的版本?

189953 次浏览
小开

我将使用x.y.z类型的版本控制

x -主要释放
y -次要释放
z -构建号

小开

基本答案是“视情况而定”。

版本控制的目标是什么?许多人使用version.revision.build并且只发布version。对世界的修订，因为这是一个发布版本，而不是一个开发版本。如果你使用签入“版本”，那么你很快就会发现你的版本号变大了。

如果你正在计划你的项目，那么我会为带有小变化的版本增加修订，为带有大变化、bug修复或功能/特性的版本增加版本。如果您提供beta版或夜间构建类型版本，则扩展版本控制以包括构建，并在每个版本中增加版本。

不过，在一天结束的时候，这取决于你，它必须对你有意义。

小开
最佳答案

您应该从版本1开始，除非您知道您“发布”的第一个版本在某种程度上是不完整的。

至于您如何增加版本，这取决于您，但是使用主要，次要，构建编号作为指导。

没有必要把你提交给源代码控制的每个版本都作为另一个版本——你很快就会有一个非常大的版本号。当您向外界发布新版本时，您只需要(以某种方式)增加版本号。

因此，如果你做了一个重大的更改，从版本1.0.0.0移动到版本2.0.0.0(例如，你从WinForms更改到WPF)。如果您做一个较小的更改，从1.0.0.0移动到1.1.0.0(您添加了对png文件的支持)。如果你做了一个小的改变，那么从1.0.0.0到1.0.1.0(你修复了一些错误)。

如果你真的想要获得详细信息，使用最终的数字作为构建号，它会在每次签入/提交时增加(但我认为这太过分了)。

小开
正如Mahesh所说: 我会使用x.y.z类型的版本控制

x -主要释放 Y -轻微释放 Z -构建号

你可能想要添加一个datetime，而不是z。

当您有另一个版本时，您将增加次要版本。 主版本可能会保持0或1，当你真正做出重大更改时(通常是当你的软件处于与以前版本不向后兼容的位置时，或者你改变了整个框架时)你才会更改它
小开

我基本上遵循这个模式:

  • 从0.1.0开始

  • 当它准备好时，我在源repo中分支代码，标记0.1.0并创建0.1.0分支，头部/主干变成0.2.0-snapshot或类似的东西

  • 我只向主干添加了新特性，但对分支进行了backport修复，并及时发布了0.1.1,0.1.2，…

  • 当产品被认为功能齐全且没有重大缺陷时，我宣布版本为1.0.0

  • 从那时起-每个人都可以决定什么时候增加主版本…

小开

你知道你总是可以看看别人在做什么。开源软件倾向于允许访问它们的存储库。例如，您可以将SVN浏览器指向http://svn.doctrine-project.org，并查看实际项目使用的版本控制系统。

版本号，标签，都有。

小开

我们用a.b.c.d

  • A -主要(在交付给客户端时增加)
  • B -小调(交付客户时增加)
  • C -修订(在内部版本上增加)
  • D - build(随巡航控制增加)
小开

我们遵循abc方法:

如果应用程序中发生了一些重大变化，则增加“a”。比如我们把。net 1.1应用程序升级到。net 3.5

如果有一些小的变化，如任何新的CR或增强，则增加'b'。

如果在代码中修复了一些缺陷，则增加'c'。

小开

A.B.C方法的另一个例子是Eclipse Bundle版本控制。Eclipse包有第四个部分:

在Eclipse中，版本号由四(4)段组成:3个整数和一个名为major.minor.service.qualifier的字符串。每个片段都抓住了不同的意图:

  • 主段表示API的破坏
  • 小段表示“对外可见”;变化
  • 服务段表示bug修复和开发流的更改
  • 限定符段指示特定的构建
小开

还有日期版本控制方案，例如:YYYY.MM， YY.MM， YYYYMMDD

它的信息量很大，因为第一眼就能给人关于发布日期的印象。但我更喜欢x.y.z方案，因为我总是想知道产品在其生命周期中的确切位置(主要。次要。发布)

小开

我在我的应用程序中使用这个规则:

x.y.z

地点:

  • X =主版本号，1-~。
  • Y =特征号，0-9。如果更改包含有或没有错误修复的新特性，则增加此数字。
  • Z =热修复数，0-~。如果更改只包含错误修复，则增加此数字。

例子:

  • 对于新应用程序，版本号以1.0.0开始。
  • 如果新版本只包含错误修复，则增加热修复数量，以便版本号为1.0.1。
  • 如果新版本包含有或没有bug修复的新特性，增加特性号并将热修复号重置为零，以便版本号为1.1.0。如果特性号达到9，增加主版本号，并将特性号和热修复程序号重置为零(2.0.0等)
小开

我从最低(非热修复)段开始版本控制。我不限制这个部分为10个。除非你在跟踪构建，否则你只需要决定当你想应用一个增量。如果你有一个QA阶段，那么你可能会应用一个增量到最低段，然后当它通过QA并发布时，再往上应用一个增量到下一个段。将最上面的部分留给主要的行为/UI更改。

如果你像我一样，你会让它成为一种混合的方法，以匹配你的软件进程的速度。

我认为最被接受的模式是a.b.c.或a.b.c.d，特别是当你将QA/合规混合在一起时。我在约会期间受到了太多的抨击，成为了版本的常规部分，所以我放弃了主流。

我不跟踪构建，所以我喜欢使用a.b.c模式，除非涉及热修复。当我必须应用热修复程序时，我应用参数d作为日期和时间。我采用d作为时间参数，因为在生产中，当事情真正爆发时，一天中总有好几次的可能性。我只应用d段(YYYYMMDDHHNN)当我为一个生产固定发散。

我个人并不反对va.b revc的软件方案，其中c是YYYYMMDDHHMM或YYYYMMDD。

话虽如此。如果你可以抓起一个工具来配置和运行它，将使你摆脱不得不整理版本控制的意见方面的头痛，你可以只说“使用该工具”…因为开发过程中的每个人通常都是所以兼容的。


提交答案