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

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


当前回答

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

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

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

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

其他回答

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

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

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

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

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

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

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

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

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

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

我们遵循abc方法:

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

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

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

我基本上遵循这个模式:

从0.1.0开始 当它准备好时,我在源repo中分支代码,标记0.1.0并创建0.1.0分支,头部/主干变成0.2.0-snapshot或类似的东西 我只向主干添加了新特性,但对分支进行了backport修复,并及时发布了0.1.1,0.1.2,… 当产品被认为功能齐全且没有重大缺陷时,我宣布版本为1.0.0 从那时起-每个人都可以决定什么时候增加主版本…