版本发布时的最佳做法

是否曾经想过如何对您的软件发行版进行版本控制？ 有没有看过您正在使用的软件，并询问他们使用的方法是什么，或者是否应该使用它？ 您是否曾经对采用哪种方法感到困惑？

我明白了，软件，就像任何复杂的人类努力一样，都不容易。 和发行版本控制没有什么不同。 而且，乍看起来似乎并不明显，但是您对软件进行版本控制的方式会对人们使用软件的方式以及对软件的想法产生重大影响。

例如，以下是用户（或系统管理员）通常会问的问题：

• 我使用的是最新版本吗？
• 我需要升级吗？
• 我是否有最新的安全补丁？

作为软件开发人员，这些问题似乎有些琐碎。 但是，作为用户- 特别是如果他们是较大组织的系统管理员 -则不是。

最近一位客户向我强调了这一事实。 我们必须讨论发行版的版本控制，他们指出，您必须注意发行版的命名约定以及发行新版本的频率。

为什么？ 你可能会问。 好吧，请考虑以下情形：一个用户几个月前购买并安装了软件的版本8，而最近您发布了一个新的主要版本。 但是，您无需将其命名为版本9，而是将其命名为9.1。 更糟糕的是，您给它起了一个人名或跳过了多个版本，例如版本14。

在内部，在您的软件团队中，您知道正在发生什么以及意味着什么。 但是请稍等片刻。 这是他们可能（可能）问自己的事情：

• 我错过了几个版本吗？
• 因为我当前的版本已经过时（可能有多个版本），所以我是否需要付费（再次）更新到新版本？
• 如果由于版本号的大幅增加而有必要升级，由于结构上的重大变化，我是否会冒丢失我（宝贵）数据的风险？
• 升级对我的业务意味着什么干扰？

也许我要越过这里。 但是我需要强调，命名很重要。 如果做对了，就可以为您的用户提供我们所有人想要的东西：一致性，可预测性和透明度。

当我们正确地做这些事情时，您会得到回报：信任您的软件而不是竞争对手的软件是他们投资的正确选择； 相信价格合理； 相信自己知道自己在做什么。

信任是无价的！

因此，如果您不确定软件的版本控制风格，我想向您展示一种行业最佳实践。 这称为语义版本控制 。

该名称可能对您来说是个新名称，但您可能已经看过无数次了。 这是三个例子。 在撰写本文时，Google Chrome的版本为63.0.3239.132 ，Firefox的版本为57.0.4 ，Mac Mail的版本为11.2 。 这三个是语义版本控制的示例。

语义版本控制如何工作？

引用semver.org，语义版本控制如下：

给定版本号MAJOR.MINOR.PATCH，增加：

进行不兼容的API更改时为MAJOR版本，以向后兼容的方式添加功能时为MINOR版本，而向后兼容的错误修复时为PATCH版本。

预发行版和构建元数据的其他标签可作为MAJOR.MINOR.PATCH格式的扩展名使用。

让我们通过一些具体的例子来说明这一点。 在撰写本文时：

• Firefox的版本为57.0.4 。 这意味着它是第57个主要版本的第四个补丁。
• Google Chrome的版本为63.0.3239 。 这表明它在版本63的第3,239个补丁中。
• Mac Mail版本为11.2 。 这意味着它是对版本11的第二次次要更新。

从这三个示例中，您可以看到语义版本控制是一个非常简洁且结构化的系统，用于对发行版进行版本控制。 公平地说，除了我在这里介绍的内容以外， 还有许多其他规则 。 但是，这些都是基础知识。

但是，即使使用了如此简洁的命名系统， 语义版本控制FAQ中仍然存在一些明显的问题要回答，例如以下两个：

我应该如何在0.yz初始开发阶段处理修订？

最简单的操作是从0.1.0开始初始开发版本，然后为每个后续版本增加次要版本。

我怎么知道什么时候发布1.0.0？

如果您的软件正在生产中使用，则可能已经是1.0.0 。 如果您拥有用户依赖的稳定API，则应为1.0.0 。 如果您担心向后兼容性，那么您应该已经是1.0.0 。

实施语义版本控制的五个技巧

除了这些问题，现在我们已经学习了语义版本控制的基础知识，在使用语义版本控制时，需要牢记五个核心注意事项。

1 –与您的用户清楚地交流

确保与用户交流您正在使用语义版本控制，它的含义以及在哪里可以找到有关它的更多信息。

如果您的用户是技术用户和非技术用户的混合使用，这尤其重要。 技术越熟练，他们越有可能（但不能保证）了解其含义。

但是，对于技术不太熟练（或比较随意）的用户，至少对于他们来说，命名风格可能不那么清晰。 因此，让他们知道这意味着什么，为什么要使用它，以及他们应该期待什么。

有许多方法可以做到这一点，但是最好的两种方法是将其作为文档的一部分并通过您的邮件列表（或其他常规的公司通讯方式）包括在内。 这样，您将帮助他们管理他们的期望，而不会因版本号的更改和增长而感到惊讶或惊慌。

2 –有一个开放的发布时间表（逐渐变化）

如果您查看语义版本控制的最重要支持者，例如Ubuntu，Firefox和Google Chrome，您会发现它们都已发布了发布时间表。

Ubuntu发布时间表

上面来自Ubuntu的屏幕截图显示了每个发行版的名称 ， 代号 ， 发行日期和寿命终止（EOL）日期 。 您会看到它分为当前 ， 将来和寿命终止版本 。

通过提供此信息，您：

• 帮助用户与您一起旅行
• 帮助他们计划支出
• 帮助他们计划何时需要预留时间和资源来升级到后续版本（主要版本，次要版本或补丁程序）。

简而言之，如果您希望用户与您合作，那么愿意与他们合作。

3 –一致且可预测

就像生活中的任何事情一样，如果您希望人们与您一起工作，则必须保持一致和可预测。 如果不是这样，您的用户将很难知道期望什么以及何时 。

如果您的发布计划每十二个月发布一个新的主要版本，请尽最大努力坚持下去。 第一次发布六个月后没有发布一个版本，然后在十二个月之后发布一个版本，而在两三年后发布另一个版本。 这样做会破坏您与用户之间建立的信任，并首先否定拥有版本控制系统的好处。

用Microsoft数到10

Microsoft Windows版本控制系统就是一个很好的例子。 Windows 10发布后不久，我在上方看到了该图像。

在看到它之前，我并没有过多考虑微软的风格。 但是，它提出了一个公平的问题： 您如何在Microsoft算到10 ？

尽管很有趣- 也许微软可以摆脱它 -但它有严肃的一面。 通过这种命名结构：

• 您如何知道您所安装的版本是最新版本还是已过期？
• 您怎么知道您使用的是最新版本？

这对于最近出现的一系列勒索软件以及Spectre和Meltdown尤其重要。

因此，请帮自己一个忙，使用语义版本控制，并保持命名风格的一致性和可预测性。 看起来很无聊。 但是，嘶嘶声出现在您的产品中， 而不是其版本号 ！

4 –定期透明地交流更改

对于每个新版本，无论是主要版本，次要版本还是修补程序，都应将更改传达给用户。 具体来说，让他们知道以下四件事：

1. 什么是新的
2. 已修复的问题
3. 有什么改进
4. 已弃用什么

这可以通过多种方式完成，但是最好的方法之一就是将其包含在发行说明中。 这就引出了一个问题：如何？ 嗯，有很多方法可以编写发行说明，但是ProdPad 提供了一些很好的建议 。 我在以下引号中对其进行了总结：

写好的发行说明供阅读，清楚地概述了改进之处以及它们如何使用户受益。 客户喜欢这种对透明度的承诺，这使他们有理由相信您。 在我们是否发布发行说明之前，我们曾被问过-可能是因为它很好地表明了我们是否兑现了我们在路线图上所承诺的目标。

将发行说明划分为多个部分时，更易于消化。 部分使用户的扫描更加容易。 撰写清晰明确的发行说明可帮助您围绕产品的进度与客户建立某种程度的沟通。

这是他们博客中的模板，因此您可以更轻松地可视化结构：

发行说明模板，版权为ProPad

5 –获取用户反馈

让我们假设您已经集中精力进行版本发布的语义版本控制，并且您已经跟踪了几个月（如果不是几年的话）。 您的用户对此有何评论？ 他们喜欢这种结构吗？ 对他们有帮助吗？ 他们有抱怨吗？ 您是否对他们来说动得太快（ 如果只是在他们的脑海中 ）？

这一点不是特定于发行版版本控制-适用于我们拥有用户或客户的任何努力。 我们必须确保我们定期与他们交谈，并找出他们的想法。

如果他们对系统感到满意，并且对他们有用，那么它将帮助他们更好地完成自己的工作，然后他们将与我们一起前进，并帮助我们不断改进它。

因此，我鼓励您在投入时间和精力来实施发布版本控制系统之后，确保与用户保持联系，收集他们的反馈并尽可能多地使用它。 毕竟，您的软件可以帮助他们，而不是您。

结论

这是版本控制软件版本的关键最佳实践。 是的，有许多方法，但是语义版本控制是软件行业中最广泛接受和实践的方法之一。

如果您还没有，我鼓励您看看当前的方法，然后看看：

1. 如果语义版本控制有所改进，
2. 它如何帮助您的用户提高清晰度和透明度，以及
3. 如何帮助您轻松地将目标传达给他们。

翻译自: https://www.javacodegeeks.com/2018/01/best-practices-versioning-release.html