version-control - 维护版本与正常版本的政策？

Question

在大型组织现场安装的应用程序需要支付支持的情况下，我的公司在维护版本与“正常”版本的问题上苦苦挣扎。首先让我定义我的条款:

想象我们已经发布了该产品的版本1.0、1.1和1.2。这些是我所谓的“普通”发行版，即它们是开发主要分支的下一个发行版，其中包含所有最新和最出色的错误修复和增强功能(每个发行版可能包含数十个)。

现在，想象一下1.0上的一些大客户报告了一个从未遇到过的节目停止问题。这个问题仍然存在于1.2中，不幸的是1.3尚未发布数周或数月。因此，我们将代码分支到1.0，以创建一个1.0.1版的“ maintenance ”发行版，其中仅包含一个可解决该问题的更改。

这种方法使客户满意，因为我们在一天左右的时间内解决了他们的问题，而不是让他们等待数周才能发布下一个正常版本。另外，由于维护版本仅包含一个小更改，因此他们不需要经过广泛的UAT流程，而如果升级到下一个正常版本(可能有多个版本)，则它们可能会收到30或40产品变更(按他们的风险规避观点)需要大量的UAT。

问题是:

创建并支持我们的软件

的多个版本对我们来说是昂贵的

它允许粘在泥泞中的客户远远落后于最新版本

它使将来最终升级这些客户的过程变得复杂，因为它们的安装与其他所有1.0客户都略有不同(如果维护版本以某种方式对其进行了升级，则升级他们的数据库特别复杂)

所以我想知道其他人在这个问题上的立场是什么？您如何在不因大量维护版本而退缩的情况下让客户满意？例如，您是否允许将某些类别的修复程序作为维护版本进行，但坚持要求其他类型的修复程序在下一个正常版本中进行？

说明性:编写没有错误的软件并不是一个完整的解决方案，因为在上述情况下出现的“问题”可能是对我们产品所依赖的外部系统的行为的不可预见的变化。

Answer 1

我建议阅读Version Control for Multiple Agile Teams，尤其是Release branches部分(对N支球队有效的方法也对1支球队有效)。

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