最佳做法,建立树干干线？

我们有许多项目使用共享组件(dll)的共同基础.目前,每个项目的开发构建都链接到从组件主干构建的dll.(即主干版本使用来自其他主干版本的dll)

当我们进行发布构建时,我们有一个脚本遍历项目文件并将中继引用替换为组件的特定编号版本(从标记分支构建)

我认为这削弱了我们在开发过程中所做的测试,因为我实际工作的项目是使用不同的dll来发布版本将使用的.我希望始终针对组件的编号版本进行开发,并且只在有特定需求时才更新它们.

然而,团队中的其他人认为除非我们针对主干进行开发(并且每个版本更新到组件的更新版本),否则我们将遇到以下问题:(a)我们的产品几乎不会更新到新版本的组件( b)当我们确实需要更新它将是一项艰巨的任务,因为组件源/接口将发生如此大的变化.

你遵循什么做法,为什么？

编辑:对不起所有,我刚刚意识到我有一些困惑的事情,提到有几个主要产品共享组件 - 虽然他们共享组件,他们不在同一台PC上运行.我关心的是这样的事实:因为组件可能随着产品的每次发布而改变(即使没有特定的更新组件的要求),测试会遗漏在组件中完成的一些微妙变化,而与组件无关正在对产品进行的具体工作.

嗯,我可能在这里占少数,但这归结为发布管理.

trunk根据定义,针对一组共享组件进行开发意味着组件是"移动目标" - 使用这些共享组件的开发人员不一定知道新发现的缺陷或故障是由于项目代码还是共享组件,导致生产力下降,IMNSHO.

"共享组件"具有自己的发布周期.让您的其他开发人员休息并修复项目将要使用和使用的共享组件的版本tags,labels或者branches识别共享组件版本.在项目的下一次迭代中,实现共享组件的最新"稳定"或"生产"构建.

如果你原谅这个表达,那里还有另一种"气味".项目发布之间的"源/接口将发生如此大的变化"的"共享组件"听起来像组件不是那么牢固或不一定要共享.

另请参阅此问题的答案所有项目中的共享组件,是否有比svn更好的替代方案:externals？