我的公司正在考虑将我们的版本号扩展另一个档次（例如从major.minor.servicepack 到major.minor.servicepack.customerfix），以允许客户特定的修复。
从表面上看，这让我觉得这是个坏主意，因为我的经验是产品的分支越多（我相信客户修复程序是代码库的分支），开销就越大，工作量越分散，最终开发效率就越低组变成。
我见过很多风险与生产力的讨论，但仅仅说“我认为这是一个坏主意”还不够。关于过于规避风险并采用繁重的、客户特定的源代码分支开发模型的实际成本有哪些文献？
一点澄清。我希望这个模型意味着客户可以控制哪些错误修复进入他们自己的私有分支。我认为他们很少会升级到通用后备箱（它甚至可能不存在于这个模型中）。我的意思是，如果你可以控制自己的私人现实泡沫，你为什么要这样做？
不能帮助文学，但客户特定的分支是一个坏主意。去过也做过。调试这些东西简直是地狱，因为当然你必须拥有所有这些客户特定的版本来重现错误......一段时间后，公司不得不对应用程序进行完全重写，因为代码库已经完全变了不可维护。（将客户特定的部分移动到配置文件中，这样每个客户都在同一个代码行上。）
不要去那里。
我同意它通常处理客户修复的开销很高，但我不会说不要这样做。
如果他们想要那么多关注，我会说向客户收取一条胳膊和一条腿（以及他们一些）。否则不要做客户分支机构。
在我的旅行中，我个人没有看到任何关于大多数良好实践的明确文献，尽管我怀疑那里有很多东西。
版本号提供了一种非常简单的机制，可以将特定的版本与特定的代码更改集联系起来。从技术上讲，版本号有多少级别并不重要，只要开发人员努力确保每发布一个“唯一”版本，都有一个“唯一”版本号。
逻辑规定，为了限制支持成本（这是巨大的，通常比开发成本更糟糕），一个合理的组织更愿意在现场运行最少数量的“独特”版本。一个会很棒，但是在现实世界中通常有很多。这是成本与便利性的问题。
通常，第一个数字表示这一系列版本不向后兼容。下一个数字说它大部分是，但有一些事情发生了变化，最后一个数字说有些东西是固定的，但文件都是正确的。使用这种方式，您不需要第四个数字，即使您已应部分客户的要求进行了一些特定的修复。选择更多地由客户端驱动不应该对您的编号方案产生任何影响（因此这是一个坏主意）。
基于客户要求的分支是绝对的疯狂。一个主干是必不可少的，因此每次分支时都会产生大量技术债务。分行够多，你再也付不起利息了。
您将进入客户分支的更改描述为“修复”。因为它们是修复，我假设它们也将在主干中制作，并且实际上只是未来错误修复的高级交付。如果是这种情况，为什么不创建一个新的“服务包”（来自问题：major.minor.servicepack）并将该版本提供给客户。
不确定文献但是......如果您甚至有机会支持客户特定的修复，那么至少有一个分支和版本控制策略似乎是明智的。尽管我希望永远不要使用该策略。
我想危险在于您最终会形成一种文化，在这种文化中，客户特定的修复变得可以接受并成为常态，而不是解决导致需要修复的真正问题。
我猜真正的成本将在很大程度上取决于它是否只是在下一个版本之前让客户满意的临时错误修复，或者它是否更像是一次性定制。如果只是前者，而且数量不是太高，我也不会太担心。但是，如果它的定制我会被吓傻。
如果您能找到一种方法来编译您的一个产品并在他们的中央构建的“配置”中打开/关闭每个客户的功能，这可能是值得弄清楚的事情。
这样的事情最好通过基于配置文件/配置/角色的设置来完成。
您可能必须保护一组客户端的自定义设置，或者他们都可以从中受益。那部分取决于你。
通过这种方式，您可以构建自定义视图、自定义代码、自定义角色、自定义代码等等。但是，它们是一个项目的一部分。
不要不惜一切代价维护同一产品的多个代码库。我做过一次，如果每个系统处于最糟糕的位置，则每个系统至少需要 1 小时进行一小时的更改。这是自杀。
一定要分享你最终做了什么！
以我的经验，当很难解释应该如何通过分支传播错误修复时，就达到了临界点。
分支地狱是一个问题，因为人们不知道哪个分支中有什么。如果传播规则过于复杂，人们在分支之间传播更改时就会开始犯错误，这就是你创建分支地狱的方式。
如果“Cisco”分支提出了一个缺陷并且我们修复了它，我们应该将修复传播到“IBM”分支的当前版本，还是只传播到“IBM”分支的下一个版本？如果 IBM 提出同样的缺陷会怎样？如果 IBM 甚至不使用包含缺陷的特性怎么办？如果 IBM 稍后提出与高优先级相同的缺陷怎么办？对于多个客户分支，传播规则从来都不是简单的，因此它们几乎可以保证分支地狱。