是否有什么指导方针或标准的最佳实践，如何在业余时间开发一个有趣的软件，但仍然会被一些人使用?我认为有必要对这样的软件进行版本化，这样你就可以知道第一版所谈论的内容(例如修复错误、支持等等)。
但是我从哪里开始版本控制呢?0.0.0吗?还是0.0 ?然后如何增加这些数字呢?主要版本。小改变?任何版本控制系统都不应该是另一个版本吗?或者这仅仅是用于生产方式的版本?
当前回答
我们用a.b.c.d
A -主要(在交付给客户端时增加) B -小调(交付客户时增加) C -修订(在内部版本上增加) D - build(随巡航控制增加)
其他回答
我会使用x.y.z类型的版本控制
X -主要释放 Y -轻微释放 Z -构建号
正如Mahesh所说: 我会使用x.y.z类型的版本控制
X -主要释放 Y -轻微释放 Z -构建号
你可能想要添加一个datetime，而不是z。
当您有另一个版本时，您将增加次要版本。 主要版本可能会保持0或1，当你真正做重大更改时(通常是当你的软件处于与以前的版本不向后兼容的位置时，或者你改变了整个框架时)，你才会更改它。
a.b.c.方法的另一个例子是Eclipse Bundle Versioning。Eclipse包有第四个部分:
在Eclipse中，版本号由四(4)段组成:3个整数和一个分别名为major.minor.service.qualifier的字符串。每个片段都抓住了不同的意图: 主段表示API的破坏 次要部分表示“外部可见”的更改 服务段表示bug修复和开发流的更改 限定符段指示特定的构建
您应该从版本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(你修复了一些错误)。
如果你真的想要获得详细信息，使用最终的数字作为构建号，它会在每次签入/提交时增加(但我认为这太过分了)。
我们用a.b.c.d
A -主要(在交付给客户端时增加) B -小调(交付客户时增加) C -修订(在内部版本上增加) D - build(随巡航控制增加)
