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

Question

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

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

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

问题是:

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

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

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