是否有什么指导方针或标准的最佳实践，如何在业余时间开发一个有趣的软件，但仍然会被一些人使用?我认为有必要对这样的软件进行版本化，这样你就可以知道第一版所谈论的内容(例如修复错误、支持等等)。
但是我从哪里开始版本控制呢?0.0.0吗?还是0.0 ?然后如何增加这些数字呢?主要版本。小改变?任何版本控制系统都不应该是另一个版本吗?或者这仅仅是用于生产方式的版本?
当前回答
a.b.c.方法的另一个例子是Eclipse Bundle Versioning。Eclipse包有第四个部分:
在Eclipse中，版本号由四(4)段组成:3个整数和一个分别名为major.minor.service.qualifier的字符串。每个片段都抓住了不同的意图: 主段表示API的破坏 次要部分表示“外部可见”的更改 服务段表示bug修复和开发流的更改 限定符段指示特定的构建
其他回答
a.b.c.方法的另一个例子是Eclipse Bundle Versioning。Eclipse包有第四个部分:
在Eclipse中，版本号由四(4)段组成:3个整数和一个分别名为major.minor.service.qualifier的字符串。每个片段都抓住了不同的意图: 主段表示API的破坏 次要部分表示“外部可见”的更改 服务段表示bug修复和开发流的更改 限定符段指示特定的构建
我会使用x.y.z类型的版本控制
X -主要释放 Y -轻微释放 Z -构建号
基本答案是“视情况而定”。
版本控制的目标是什么?许多人使用version.revision.build并且只发布version。对世界的修订，因为这是一个发布版本，而不是一个开发版本。如果你使用签入“版本”，那么你很快就会发现你的版本号变大了。
如果你正在计划你的项目，那么我会为带有小变化的版本增加修订，为带有大变化、bug修复或功能/特性的版本增加版本。如果您提供beta版或夜间构建类型版本，则扩展版本控制以包括构建，并在每个版本中增加版本。
不过，在一天结束的时候，这取决于你，它必须对你有意义。
我们遵循abc方法:
如果应用程序中发生了一些重大变化，则增加“a”。比如我们把。net 1.1应用程序升级到。net 3.5
如果有一些小的变化，如任何新的CR或增强，则增加'b'。
如果在代码中修复了一些缺陷，则增加'c'。
还有日期版本控制方案，例如:YYYY。嗯，yy。嗯，yyyymmdd
它的信息量很大，因为第一眼就能给人关于发布日期的印象。但我更喜欢x.y.z方案，因为我总是想知道产品在其生命周期中的确切位置(主要。次要。发布)
