是否有什么指导方针或标准的最佳实践，如何在业余时间开发一个有趣的软件，但仍然会被一些人使用?我认为有必要对这样的软件进行版本化，这样你就可以知道第一版所谈论的内容(例如修复错误、支持等等)。
但是我从哪里开始版本控制呢?0.0.0吗?还是0.0 ?然后如何增加这些数字呢?主要版本。小改变?任何版本控制系统都不应该是另一个版本吗?或者这仅仅是用于生产方式的版本?
当前回答
我们用a.b.c.d
A -主要(在交付给客户端时增加) B -小调(交付客户时增加) C -修订(在内部版本上增加) D - build(随巡航控制增加)
其他回答
我基本上遵循这个模式:
从0.1.0开始 当它准备好时，我在源repo中分支代码，标记0.1.0并创建0.1.0分支，头部/主干变成0.2.0-snapshot或类似的东西 我只向主干添加了新特性，但对分支进行了backport修复，并及时发布了0.1.1,0.1.2，… 当产品被认为功能齐全且没有重大缺陷时，我宣布版本为1.0.0 从那时起-每个人都可以决定什么时候增加主版本…
我会使用x.y.z类型的版本控制
X -主要释放 Y -轻微释放 Z -构建号
我们遵循abc方法:
如果应用程序中发生了一些重大变化，则增加“a”。比如我们把。net 1.1应用程序升级到。net 3.5
如果有一些小的变化，如任何新的CR或增强，则增加'b'。
如果在代码中修复了一些缺陷，则增加'c'。
还有日期版本控制方案，例如:YYYY。嗯，yy。嗯，yyyymmdd
它的信息量很大，因为第一眼就能给人关于发布日期的印象。但我更喜欢x.y.z方案，因为我总是想知道产品在其生命周期中的确切位置(主要。次要。发布)
你知道你总是可以看看别人在做什么。开源软件倾向于允许访问它们的存储库。例如，您可以将SVN浏览器指向http://svn.doctrine-project.org，并查看实际项目使用的版本控制系统。
版本号，标签，都有。
