关于软件版本控制的问题

Question

对于软件版本控制，我有一个小小的疑问，我知道有很多方法可以做到，但最常见的是数字，长度为3到4位，我知道这种方法中的每个数字意味着什么，我的怀疑是两个，但它们是并行不悖的(我澄清了，这样我就不会忽略无重点/宽泛的问题)。

1.第一次发布的软件的版本应该如何？

我解释说:我曾多次看到过0.1或0.0.1版本的软件，那么这是怎么回事，所有的软件都应该从零开始吗？然而，有时我看到其他人的第一个版本是1.0.0.0。我读过关于软件版本控制的通用标准，但我认为需要考虑一些事情，这就解释了为什么一些开发人员从0.1开始，而其他开发人员则从1.0开始(除非其中一个开发人员做错了事情)。在其他情况下，我看到版本没有完全遵循，但例如，一个版本是1.10，下一个版本是1.15，也就是说，它们不会从一个版本增加到另一个版本，但不会从一个版本增加到另一个版本。

2.在独立开发人员的情况下，推荐使用什么长度？

我解释说:在数字方法中，我看到两种常见的形式，即3位数和4位数，而第四种是“交付/修订次数”，即当产品被拒绝时发生变化。这个概念让我明白，只适用于开发软件的公司，不符合某些参数的公司，我不知道，那么，对于独立开发人员来说，使用三位数模式更好。

如果这是一个很长的问题，我很抱歉，让我们集中讨论一下数字方法。我再说一遍，我知道这方面没有标准，但我想知道为何互联网上有这么多版本的方法，以及哪种方法是不正确的。

Answer 1

版本控制是非常固执己见的。没有那么多标准，但也有一些约定。对于公共API(如web或库中提供的API)，语义版本化是一种常见的约定，有一些工具可以执行它。然而，并不是所有的项目都能利用它，也没有给应用程序开发人员提供太多的帮助。

第一次发布软件的版本应该是怎样的？

这取决于你的申请。

在语义版本控制中，以0开头的任何内容都被认为是不稳定的。您不稳定的早期版本(如果您选择公开这些版本)将是0.x.y格式的。一旦您的API稳定下来，您将发布1.0.0并从那里开始。但是，正如我前面提到的，语义版本控制只会对库有所帮助。您可以尝试在此方案上建模您的版本控制，但我不知道任何有文档的约定。

从技术上讲，您不需要三个(或四个)点版本号。您可以使用生成或发布日期、随机名称、单个版本号，或者可能根本没有版本号。维基百科关于软件版本控制的文章给出了几个例子。

某种一致性或在逻辑时间点更改版本控制是很重要的。在您的自述文件中包含一些关于开发和维护水平的内容将是一个好主意。我希望任何以专业身份使用该软件的人都能尽职尽责，并评估第三方软件的质量，以支持他们的开发。

如果是独立开发人员，推荐的长度是多少？

这并不是说谁在做开发，而是在做什么样的软件开发。API与应用程序是思考开发的一种方法。应用程序的自托管与SaaS是另一个考虑因素。考虑您正在进行版本控制的内容，以及需要与涉众沟通的内容，是选择版本控制方案的好方法。

Answer 2

上下文

这里是至高无上的。

• 某些包管理器至少为通过它们的通道发布的包规定了一个特定的版本控制方案。
• 某些开发工具将为您自动管理特定方案中的版本信息，使使用该方案比其他方案容易得多。
• 某些用户组将更喜欢一个或另一个版本控制方案。与大多数非专业人士的对话一样，他们将讨论2018年计划，而不是构建10.3.2.1351，作为开发人员，他们对提交的具体内容更感兴趣。

至于0.x，这要看情况。

• 一些方案，如语义版本控制，将其视为正式版本(1.x)之前的原型版本。
• 有些方案只是将其视为第一个版本(许多开源库都是这样做的，并且可以保持这种状态多年/几十年)。
• 有些计划跳过了这一切

到底是对还是错？如果您无法识别确切的源、依赖项和二进制格式中的特定构建，则只会做错事。

不过，如果你：

• 标识正在使用的方案。
• 解释两个不同的版本号是如何相互发布映射的。假设您必须在不同的版本方案中发布。
• 在遵循版本控制方案时要保持一致。
• 使用一个与听众进行有意义的交流的方案。是使用日期，还是使用像x.y.z这样的合成版本号？