我的公司正在浮动将我们的版本号扩展到另一个等级的想法(例如从major.minor.servicepack到major.minor.servicepack.customerfix)以允许客户特定的修复.
这让我觉得表面上是一个坏主意,因为我的经验是产品分支越多(我认为客户修复是代码库的分支),开销越大,工作量越少,最终开发效率越低小组成了.
我已经看到了很多风险与生产力的讨论,但只是说"我认为这是一个坏主意"还不够.什么样的文献有关于过度厌恶风险并采用重要的,客户特定的源代码分支,开发模式的实际成本？
一点澄清.我希望这个模型意味着客户可以控制哪些错误修复进入他们自己的私有分支.我认为他们很少升级到一般主干(在这个模型中甚至可能不存在).我的意思是,如果你能控制自己的私人现实泡沫,为什么会这样？
在一个可以每天创建多个构建(发布候选包)但每月只有一个被提升为生产的环境中,我认为将每个构建存储在Git中都会浪费,但应该有一个短期位置,最后几个构建版本发布.
我目前正在将这些发布到共享目录.我看到IVY过去常用于这种二进制发布.Git看起来有点矫枉过正,因为它的模型永远不会删除任何内容.
管理/发布这些瞬态构建工件是否有一种商定的标准化方法？