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

Question

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

• 想象一下，我们已经发布了该产品的1.0,1.1和1.2版本。这就是我所说的“普通”版本，即它们是开发主要分支的下一个版本，包含所有最新和最好的错误修复和增强功能（每个版本可能需要几十个）。 / LI>
• 现在想象一下1.0上的一些重要客户报告了一个没有人遇到过的停止问题。这个问题在1.2中仍然存在，遗憾的是1.3几周或几个月都没有问题。因此，我们将代码分支为1.0以创建1.0.1“维护”版本，其中只包含一个修复问题的更改。

这种方法让客户感到高兴，因为我们会在一天左右的时间内解决问题，而不是让他们等待几个星期，直到下一次正常发布。此外，由于维护版本只包含一个小的更改，它们不需要经过广泛的UAT过程，而如果它们升级到下一个正常版本（可能是几个版本），它们将接收可能30或40产品变化（在他们的风险规避观点中）需要广泛的UAT。

问题在于：

• 创建和支持我们软件的多个版本对我们来说代价很高
• 它允许坚持到底的客户远远落后于最新版本
• 这使得最终升级这些客户的过程变得复杂，因为他们的安装与其他1.0客户略有不同（如果维护版本以某种方式改变了数据库，升级他们的数据库会特别复杂）。

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

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

Answer 1

我建议阅读Version Control for Multiple Agile Teams，特别是Release branches部分（适用于N队的工作也适用于1个团队）。

从我到目前为止所阅读的各种答案和评论中，你可能会发现一些好的建议。

Answer 2

不幸的是，在与第一位客户签订任何合同之前，您需要做出决定。如果它不在合同中，则不存在。

对于收缩膜包装，你不应该在乎。没有合同，所以您没有义务提供任何支持。无论保持良好关系的愿望如何。事实上，你已经从过去的客户那里得到了你的钱。永久地支持他们将立即削减已经收到的利润。如果您真的想要转移到服务模型，则不能在shrinkwrap中销售该软件。 （想想防病毒软件。你停止付费，他们不再更新了。）

列出您网站上的日期列表，了解何时停止支持过去的版本并坚持下去。如果他们不喜欢它，他们可以寻找新的软件。你永远不能保证未来的销售。

编辑，回应评论：然后，正如我所说，你的问题是你的合同。如果他们没有给你权力说“你必须升级”或“我们不支持超过最后三个小版本”那么你的公司就搞砸了。展望未来，你应该确保你未来的合同确实包含这样的语言。持续支持仅表示合同所指的含义。

Answer 3

我们只为客户创建一个版本，我们每天都会进行构建和单元测试（你做都有，不是吗？）

有了这两个，我们可以根据需要频繁推出代码，因此无需担心维护版本或正常版本。只有一份副本值得使用，这是最新版本。

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

Answer 4

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

您可以做的最好的事情是鼓励客户升级，可能默认情况下自动更新。如果你的客户觉得很多UAT是必要的，你可能会因为更新破坏了他们依赖的东西而烦恼他们，然后修复需要一段时间才能出来。如果是这样，请考虑改进测试和质量保证流程。

我不确定你还能做些什么来改善这一点。

Answer 5

我们同时拥有维护和正常版本。

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

Answer 6

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

1. 为错误修正创建主题分支，在最早的时候将其分支（例如1.0版本），例如命名为'富-缺陷修复'
2. 为版本维护版本创建新分支，例如1.0，如果它还不存在，并且如果此版本中存在bug，则命名为e。，g。 'MAINT-1.0'
3. 将错误修复分支合并到维护分支中，解决冲突（如果有）。
4. 根据需要修改版本号。标记新的维护版本，例如'1.0.1'
5. 对于您要支持的其他版本重复2-4

通常，您只为最后一个项目版本执行维护版本（在名为“maint”或“维护”的分支上）。但是，我认为，如果您发现严重的错误（例如严重的安全漏洞），将其修复到受影响的所有版本（可能仅限于不太旧/仍然广泛使用的版本），这是一个很好的做法。

HTH

Answer 7

我建议总是要求客户至少尝试最新的点发布：从1.0移动到1.1，看看是否能解决问题。第一个问题。

这有助于确保您在点发布中不添加任何新功能，除非它们涵盖了软件中的一个重要功能漏洞。制作仅用于修复错误的点发布，最多用于删除不良的功能设计。 保存新功能，将您的客户集中用于回购您的产品:-)

不引入点发布的新功能也可能降低客户对新bug的引入的恐惧;在安装新版本时，它们通常被保留的原因。

如果客户仍然遇到您当前的积分问题而且紧急他可以获得“修补程序”。如果当前点版本是1.2，则修补程序可以包含在提供给客户的1.3的预发行版中。 这个急需的客户现在实际上正在帮助您测试不稳定点发布，还可以帮助您提供有关点发布中其他一些更改的反馈。 执行单个修复小版本，一旦客户帮助您测试它​​，您就可以将其合并回待处的版本。

这与Microsoft的Service Pack方法相比：经常发布修补程序，然后在Service Pack中将它们一起收集（ - ＆gt; point release）。在广泛发布的修补程序经常与面临问题的客户一起进行测试之前，修补程序无法修复。

你绝对想要避免的是拥有“1.0.1客户A”和“1.0.1客户B”，你正在邀请复杂性和维护地狱。

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