在大型组织现场安装应用程序并支付支持费用的情况下,我的公司正在努力解决维护版本与“正常”版本的问题。首先让我定义我的术语:
- 假设我们已经发布了产品的 1.0、1.1 和 1.2 版本。这些是我所说的“正常”版本,即它们是主要开发分支的下一个版本,包含所有最新和最强大的错误修复和增强功能(每个版本可能有数十个)。
- 现在想象一下 1.0 上的一些大客户报告了一个以前没有人遇到过的令人震惊的问题。这个问题在 1.2 中仍然存在,不幸的是 1.3 不会在几周或几个月后发布。因此,我们在 1.0 分支代码以创建 1.0.1“维护”版本,其中仅包含解决问题的一项更改。
这种方法让客户很高兴,因为我们在一天左右的时间内解决了他们的问题,而不是让他们等待数周直到下一个正常版本。此外,由于维护版本只包含一个小的更改,他们不需要经过广泛的 UAT 过程,而如果他们升级到下一个正常版本,可能会有几个版本,他们可能会收到 30 或 40 (在他们厌恶风险的观点中)需要大量 UAT 的产品变更。
问题是:
- 创建和支持我们软件的多个版本对我们来说成本很高
- 它允许顽固的客户远远落后于最新版本
- 它使将来最终升级这些客户的过程变得复杂,因为他们的安装与所有其他 1.0 客户略有不同(如果维护版本以某种方式对其进行了更改,则升级他们的数据库特别复杂)
所以我想知道其他人在这个问题上的立场是什么?您如何在不通过大量维护版本为您自己背锅的情况下让客户满意?例如,您是否允许某些类别的修复作为维护版本完成,但坚持其他类型的修复在下一个正常版本中完成?
澄清:编写没有错误的软件并不是一个完整的解决方案,因为上述上下文中的“问题”可能是我们产品所依赖的外部系统行为的不可预见的变化。