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