You describe the changes that go into the customer branch as "fixes". Because they are fixes, I am assuming that they will also be made in the trunk and are really just advanced deliveries of future bug fixes. If this is the case, why not just create a new "servicepack" (from question: major.minor.servicepack) and give that version to the customer.
For example, you release version 1.2.3.
Customer #1 needs a fix, create version 1.2.4 and give it to Customer #1.
Customer #2 needs a fix, crate version 1.2.5, give it to Customer #2 and advertise that they also get interim fix "for free".
In my travels I haven't personally seen any definite literature for most of the good practices, although I suspect that there is a lot of stuff out there.
Versions numbers provide a really simple mechanism to tie back specific versions in the wild with specific sets of code changes. Technically, it doesn't matter how many levels are in the version number, so long as the developers are diligent in insuring that for every "unique" version released, there is a "unique" version number.
Logic dictates that to limit support costs (which are huge, often worse then development ones), a reasonable organization would prefer to have the least number of "unique" versions running around in the field. One would be awesome, however there are usually quite a few in the real world. It's a cost vs. convenience issue.
Usually, the first number indicates that this series of releases is not backward compatible. The next number says that it mostly is, but a few things have changed and the last number says some stuff was fixed, but the documents all hold true. Used that way, you don't need a fourth number, even if you've done some specific fixes at the request of a subset of your customers. The choice to become more client-driven shouldn't have any effect on your numbering scheme (and thus it's a bad idea).
Branching based on customer requests is absolute madness. One main trunk is essential, so each time you branch it creates massive technical debt. Branch enough, and you can't afford the interest anymore.
Can't help with literature, but customer-specific branching is a bad idea. Been there, done that. Debugging the stuff was pure hell, because of course you had to have all those customer-specific versions available to reproduce the error... some time later, the company had to do a complete rewrite of the application because the code base had become utterly unmaintainable. (Moving the customer-specific parts into configuration files so every customer was on the same code line.)
If you can find a way to compile your one product and turn on each client's features on/off in their "configuration" of a central build that might be something worth figuring out.
Something like this might best be done through a profile/config/role based setup.
You may have to secure one set of client's customizations from another, or maybe they can all benefit from it. That part is up to you.
This way you can build custom views, custom codes, custom roles, custom code, whatever. But, they're a part of one project.
Do not maintain multiple codebases of the same product at any cost. I did it once and doing an hour change takes at least 1 hour for each system if it's in the worst spot. It's suicide.
Not sure about the literature but... if there is even a chance that you are supporting customer specific fixes it seems sensible to at least have a branching and versioning strategy in place. Although I would be hoping for the strategy never to be used.
I guess the danger is you end up with a culture where customer specific fixes become acceptible and the norm, rather than addressing the true issue that resulted in the need for the fix.
I guess the real cost will largely be dependent on whether its just an interim bug fix to keep a customer happy prior to the next release or whether its more of a one-off customisation. If it is just the former, and the quantity isn't too high I wouldn't be too woried. However if its customisations i would be scared witless.
如果“Cisco”分支出现缺陷并且我们修复了它，我们应该将修复传播到“IBM”分支的当前版本，还是仅传播到“IBM”分支的下一个版本？ 如果 IBM 提出同样的缺陷怎么办？ 如果 IBM 甚至不使用包含缺陷的功能怎么办？ 如果 IBM 后来将同样的缺陷列为高优先级怎么办？ 对于多个客户分支，传播规则从来都不是简单的，因此它们几乎保证了分支地狱。
In my experience, the tipping point is reached when it becomes difficult to explain how bugfixes should be propagated through the branches.
Branching hell is an issue because people lose track of what is in which branch. If propagation rules are too complex, people start making mistakes while propagating changes between branches, and that's how you create branching hell.
If the "Cisco" branch raised a defect and we fix it, should we propagate the fix to the current release of the "IBM" branch, or only to the next release of the "IBM" branch? What if IBM raised the same defect? What if IBM doesn't even use the feature that contains the defect? What if IBM later raises the same defect as high priority? With multiple customer branches propagation rules are never simple, so they pretty much guarantee branching hell.
发布评论
评论（7）
您将进入客户分支的更改描述为“修复”。 因为它们是修复，所以我假设它们也将在主干中进行，并且实际上只是未来错误修复的高级交付。 如果是这种情况，为什么不创建一个新的“servicepack”（来自问题：major.minor.servicepack）并将该版本提供给客户。
You describe the changes that go into the customer branch as "fixes". Because they are fixes, I am assuming that they will also be made in the trunk and are really just advanced deliveries of future bug fixes. If this is the case, why not just create a new "servicepack" (from question: major.minor.servicepack) and give that version to the customer.
在我的旅行中，我个人并没有看到任何关于大多数良好实践的明确文献，尽管我怀疑那里有很多东西。
版本号提供了一种非常简单的机制，可以将特定版本与特定的代码更改集联系起来。 从技术上讲，版本号有多少级别并不重要，只要开发人员努力确保发布的每个“唯一”版本都有一个“唯一”版本号即可。
逻辑表明，为了限制支持成本（这是巨大的，通常比开发成本更糟糕），一个合理的组织更愿意在现场运行最少数量的“独特”版本。 有一个就很棒了，但现实世界中通常有很多。 这是成本与便利性的问题。
通常，第一个数字表示该系列版本不向后兼容。 下一个数字表示大部分情况是这样，但有一些事情发生了变化，最后一个数字表示一些内容已修复，但这些文件都是正确的。 通过这种方式使用，您不需要第四个数字，即使您已经根据部分客户的请求完成了一些特定的修复。 选择更加以客户为导向，不应该对您的编号方案产生任何影响（因此这是一个坏主意）。
根据客户请求进行分支绝对是疯狂的。 一个主干是必不可少的，因此每次分支时都会产生大量的技术债务。 分行够多了，你就付不起利息了。
In my travels I haven't personally seen any definite literature for most of the good practices, although I suspect that there is a lot of stuff out there.
Versions numbers provide a really simple mechanism to tie back specific versions in the wild with specific sets of code changes. Technically, it doesn't matter how many levels are in the version number, so long as the developers are diligent in insuring that for every "unique" version released, there is a "unique" version number.
Logic dictates that to limit support costs (which are huge, often worse then development ones), a reasonable organization would prefer to have the least number of "unique" versions running around in the field. One would be awesome, however there are usually quite a few in the real world. It's a cost vs. convenience issue.
Usually, the first number indicates that this series of releases is not backward compatible. The next number says that it mostly is, but a few things have changed and the last number says some stuff was fixed, but the documents all hold true. Used that way, you don't need a fourth number, even if you've done some specific fixes at the request of a subset of your customers. The choice to become more client-driven shouldn't have any effect on your numbering scheme (and thus it's a bad idea).
Branching based on customer requests is absolute madness. One main trunk is essential, so each time you branch it creates massive technical debt. Branch enough, and you can't afford the interest anymore.
我同意处理客户修复的开销通常很高，但我不会说不要这样做。
我想说，如果顾客想要那么多的关注，就向他们收取一条胳膊和一条腿的费用（还有一些）。 否则不要做客户分支机构。
I agree its generally the overhead to handle customer fixes is high, but I wouldn't say don't do it.
I would say charge the customer an arm and a leg (and them some) if they want that much attention. Otherwise don't do customer branches.
无法提供文献帮助，但特定于客户的分支是一个坏主意。 去过也做过。 调试这些东西简直就是地狱，因为当然你必须拥有所有这些客户特定的版本可用才能重现错误......一段时间后，公司必须完成< /em> 重写应用程序，因为代码库已经变得完全无法维护。 （将客户特定的部分移至配置文件中，以便每个客户都在同一代码行上。）
不要去那里。
Can't help with literature, but customer-specific branching is a bad idea. Been there, done that. Debugging the stuff was pure hell, because of course you had to have all those customer-specific versions available to reproduce the error... some time later, the company had to do a complete rewrite of the application because the code base had become utterly unmaintainable. (Moving the customer-specific parts into configuration files so every customer was on the same code line.)
Don't go there.
如果您能找到一种方法来编译您的一个产品，并在中央构建的“配置”中打开/关闭每个客户端的功能，这可能是值得考虑的事情。
像这样的事情最好是通过基于配置文件/配置/角色的设置完成。
您可能必须保护一组客户的定制免受另一组客户的定制的影响，或者也许他们都可以从中受益。 这部分取决于你。
通过这种方式，您可以构建自定义视图、自定义代码、自定义角色、自定义代码等等。 但是，它们是一个项目的一部分。
不要不惜一切代价维护同一产品的多个代码库。 我做过一次，如果每个系统处于最差的位置，则进行一小时的更改至少需要 1 小时。 这是自杀。
分享你最终做了什么！
If you can find a way to compile your one product and turn on each client's features on/off in their "configuration" of a central build that might be something worth figuring out.
Something like this might best be done through a profile/config/role based setup.
You may have to secure one set of client's customizations from another, or maybe they can all benefit from it. That part is up to you.
This way you can build custom views, custom codes, custom roles, custom code, whatever. But, they're a part of one project.
Do not maintain multiple codebases of the same product at any cost. I did it once and doing an hour change takes at least 1 hour for each system if it's in the worst spot. It's suicide.
Do share what you end up doing!
不确定文献，但是......如果您有机会支持特定于客户的修复，那么至少制定分支和版本控制策略似乎是明智的。 尽管我希望该策略永远不会被使用。
我想危险在于你最终会形成一种文化，在这种文化中，客户特定的修复变得可以接受并成为常态，而不是解决导致需要修复的真正问题。
我想真正的成本将在很大程度上取决于它是否只是在下一个版本之前让客户满意的临时错误修复，或者是否更多的是一次性定制。 如果只是前者，而且数量不是太多，我就不会太担心。 但如果它是定制的，我会害怕得不知所措。
Not sure about the literature but... if there is even a chance that you are supporting customer specific fixes it seems sensible to at least have a branching and versioning strategy in place. Although I would be hoping for the strategy never to be used.
I guess the danger is you end up with a culture where customer specific fixes become acceptible and the norm, rather than addressing the true issue that resulted in the need for the fix.
I guess the real cost will largely be dependent on whether its just an interim bug fix to keep a customer happy prior to the next release or whether its more of a one-off customisation. If it is just the former, and the quantity isn't too high I wouldn't be too woried. However if its customisations i would be scared witless.
根据我的经验，当难以解释如何通过分支传播错误修复时，就达到了临界点。
分支地狱是一个问题，因为人们不知道哪个分支里有什么。 如果传播规则太复杂，人们在分支之间传播更改时就会开始犯错误，这就是创建分支地狱的方式。
如果“Cisco”分支出现缺陷并且我们修复了它，我们应该将修复传播到“IBM”分支的当前版本，还是仅传播到“IBM”分支的下一个版本？ 如果 IBM 提出同样的缺陷怎么办？ 如果 IBM 甚至不使用包含缺陷的功能怎么办？ 如果 IBM 后来将同样的缺陷列为高优先级怎么办？ 对于多个客户分支，传播规则从来都不是简单的，因此它们几乎保证了分支地狱。
In my experience, the tipping point is reached when it becomes difficult to explain how bugfixes should be propagated through the branches.
Branching hell is an issue because people lose track of what is in which branch. If propagation rules are too complex, people start making mistakes while propagating changes between branches, and that's how you create branching hell.
If the "Cisco" branch raised a defect and we fix it, should we propagate the fix to the current release of the "IBM" branch, or only to the next release of the "IBM" branch? What if IBM raised the same defect? What if IBM doesn't even use the feature that contains the defect? What if IBM later raises the same defect as high priority? With multiple customer branches propagation rules are never simple, so they pretty much guarantee branching hell.