维护版本与正常版本的政策？答案

【问题标题】：Policy on maintenance releases vs normal releases?维护版本与正常版本的政策？
【发布时间】：2010-11-25 12:44:26
【问题描述】：

在大型组织现场安装应用程序并支付支持费用的情况下，我的公司正在努力解决维护版本与“正常”版本的问题。首先让我定义我的术语：

假设我们已经发布了产品的 1.0、1.1 和 1.2 版本。这些就是我所说的“正常”版本，即它们是主要开发分支的下一个版本，包含所有最新和最强大的错误修复和增强功能（每个版本可能有数十个）。
现在想象一下 1.0 版的一些大客户报告了一个以前没有人遇到过的令人震惊的问题。这个问题在 1.2 中仍然存在，不幸的是 1.3 不会在几周或几个月后发布。因此，我们在 1.0 中对代码进行分支以创建 1.0.1“maintenance”版本，其中仅包含解决问题的一项更改。

这种方法让客户很高兴，因为我们在一天左右的时间内解决了他们的问题，而不是让他们等上几周才能发布下一个正常版本。此外，由于维护版本仅包含一个小更改，因此他们不需要经过广泛的 UAT 过程，而如果他们升级到下一个正常版本，可能会有多个版本，他们可能会收到 30 或 40 （在他们厌恶风险的观点中）需要大量 UAT 的产品变更。

问题是：

创建和支持软件的多个版本对我们来说成本很高
它允许顽固的客户远远落后于最新版本
这会使将来最终升级这些客户的过程变得复杂，因为他们的安装与所有其他 1.0 客户都有细微的不同（如果维护版本以某种方式对其进行了更改，则升级他们的数据库尤其复杂）

所以我想知道其他人在这个问题上的立场是什么？您如何在不通过大量维护版本为您自己背锅的情况下让客户满意？例如，您是否允许在维护版本中完成某些类别的修复，但坚持在下一个正常版本中完成其他类型的修复？

澄清：编写没有错误的软件并不是一个完整的解决方案，因为上述上下文中的“问题”可能是我们产品所依赖的外部系统的行为发生不可预见的变化。

【问题讨论】：

标签： version-control maintenance release-management policy

【解决方案1】：

我建议阅读 Version Control for Multiple Agile Teams 尤其是 Release branches 部分（适用于 N 团队的内容也适用于 1 个团队）。

从我目前阅读的各种答案和 cmets 中，您可能会在其中找到一些好的建议。

【讨论】：

事实上，我们刚刚按照这些思路修改了我们的发布政策，非常感谢！
@Andrew 不客气。我们正在使用非常相似的东西并且对它非常满意。

【解决方案2】：

我的建议是始终要求客户至少尝试最新的单点版本：从 1.0 升级到 1.1，看看是否能解决他们的问题。提出的第一个问题。

这里的帮助是确保您在单点版本中不添加任何新功能，除非它们涵盖了软件中的一个大功能漏洞。制作仅用于修复错误并且最多用于删除不良功能设计的发布版本。保存新功能，让您的客户重新购买您的产品 :-)

不通过点发布引入新功能也可能会降低您的客户对引入新错误的恐惧；在安装新版本时通常保留它们的原因。

如果客户仍然对您当前的单点版本有疑问，并且很紧急，他可以得到一个“修补程序”。如果当前的点版本是 1.2，则修补程序可能包含在提供给客户的 1.3 的预发布版本中。这位有紧迫感的客户现在实际上正在帮助您测试不稳定的单点发布，并且还可以帮助就单点发布中的一些其他更改提供反馈。也可以选择在客户帮助您测试后合并回待定点版本的单个修复小版本。

这与 Microsoft 的服务包方法相比：经常发布修补程序，然后将它们一起收集到服务包中（-> 点发布）。在广泛发布修补程序之前，通常会与面临问题的客户一起测试补丁程序。

您绝对想要避免的是“1.0.1-客户 A”和“1.0.1-客户 B”会导致复杂性和维护问题。

通常，您应该始终将补丁合并回您的主线。如果您的客户正在帮助您为最新版本创建补丁，请接受它。

【讨论】：

【解决方案3】：

很遗憾，在与第一位客户签订任何合同之前，您需要先确定这一点。如果合同中没有，则不存在。

对于收缩包装，您不必在意。没有合同，因此您没有义务提供任何支持。不顾一切维持良好关系的愿望。事实上，你已经从过去的客户那里拿到了钱。永久支持他们将立即将已经获得的利润减少到一无所有。如果你真的想转向服务模式，你就不能以收缩包装的形式销售软件。（想想杀毒软件。你停止付费，他们停止更新。）

在您的网站上列出您将停止支持过去版本并坚持使用的日期列表。如果他们不喜欢它，他们可以寻找新的软件。您永远无法保证未来的销售。

编辑，回应评论：那么，正如我所说，你的问题是你的合同。如果他们不给你权力说“你必须升级”或“我们不支持超过最后三个次要版本”，那么你的公司就完蛋了。展望未来，您应该确保您未来的合同确实包含此类语言。持续支持仅意味着合同规定的含义。

【讨论】：

我可能错误地使用了术语“shrinkwrap”。我已更新问题以更好地反映产品的性质。简短的版本：p *** 关闭客户不是一种选择！ :-) 但我喜欢取消对已发布时间表的旧版本支持的想法；这将有助于最小化问题的范围。

【解决方案4】：

以下工作流程可能对您有所帮助（但 YMMV）：

为错误修复创建一个主题分支，在最早的时候将其分支（例如 1.0 版本），命名为例如'foo-bugfix'
为版本的维护版本创建新分支，例如1.0，如果它还不存在，如果这个版本存在bug，命名为e.,g. 'maint-1.0'
将错误修复分支合并到维护分支中，如果有冲突则解决。
根据需要修改版本号。标记新的维护版本，例如'1.0.1'
对您想要支持的其他版本重复 2-4

虽然您通常只为项目的最后一个版本进行维护发布（在名为“maint”或“maintenance”的分支上）。但是，我认为，如果您发现严重的错误（例如严重的安全错误）在所有受影响的版本上修复它（也许将自己限制在不太旧/仍然被广泛使用的版本）上，这是一种很好的做法。

HTH

【讨论】：

【解决方案5】：

我们只为我们的客户创建一个版本，并且我们每天进行构建和单元测试（您确实两者都有，不是吗？）

有了这两个，我们几乎可以随心所欲地推出我们的代码，因此无需担心维护发布或正常发布。只有一个副本值得使用，而且是最新的副本。

编辑：当谈到“OMG 我们的功能已经完成了一半，但我们仍然需要现在发布它，是的，我的意思是现在！”我们会怎么做要做的是我们只标记新功能（使用preprocessor directive）并确保在构建期间，标记内的所有代码都被简单地注释掉。

【讨论】：

customer=>customers，我的回复有问题:)
即使使用了持续集成（我们确实有），您仍然可能会遇到一个情况，即您距离完成一个大型功能还有一周或更长时间，因此您无法正确发布主分支现在。在这种情况下，您是否会发布最新版本（上例中为 1.2.1）的维护版本，而不是他们当前所在的版本？这至少会减少版本的扩散，即使它仍然让客户在需要修复时不得不突然执行大量 UAT。
我们是一家 Java 商店，我不知道任何与预处理器指令等效的东西，但我看不出它们在部分实现的功能对在该功能之外使用的系统部分。无论如何，我认为可以通过从上一个版本分支并在那里进行所需的修复来实现相同的结果（即省略新提交的代码）。

【解决方案6】：

我们确实有维护版本和正常版本。

假设我们正在开发 5.5 版本，而客户发现以前版本中的一些问题可能在 5.4.0.1 中，我们将在 5.4.1.0 中为他们提供解决方案，并在我们当前版本（即 5.5）中进行修改通过这种方式，我们尝试关闭当前版本中的先前问题，并在旧版本中向客户提供新工具包

【讨论】：

这就是我们目前正在做的事情，但您还没有说明如何最大程度地减少为多个先前版本创建维护版本的痛苦。您指的是多少已安装的客户？
为此，您必须说服客户他们应该选择升级版，即当前版本。我们现在遵循的流程适用于审核已交付的版本或我们正在处理的版本。如果它是一个紧急版本，那么 QA 团队希望我们遵循这个过程，即使它是 3-4 天的周期。

【解决方案7】：

客户至上。您将不得不忍受支持您的软件的多个版本，因为有些客户不会升级。这是生活中令人讨厌的事实。您可以在软件开发的某些领域（例如 webapps - 任何人仍在运行原始版本的 gmail 吗？）稍微减轻它，但即使在那些类型的瘦客户端环境中，人们仍然不会升级瘦客户端（IE6 任何人？） .

您能做的最好的事情就是鼓励客户升级，也许是通过默认自动更新。如果您的客户认为需要大量 UAT，那么您可能之前通过更新破坏了他们所依赖的东西而让他们不高兴，然后修复了需要一段时间才能出来的问题。如果是这样，请考虑改进您的测试和 QA 流程。

遗憾的是，我不确定您还能做些什么来改善这一点。

【讨论】：

关于通过适当的 QA 建立客户对升级的信任的要点。
在他描述的环境中自动更新是不可接受的。仅使用 UAT 一词表明这些公司可能是风险厌恶的。自动更新和风险规避不能混为一谈。