我们有许多项目使用共享组件（dll）的共同基础。 目前，每个项目的开发构建都链接到从组件主干构建的dll。 （即主干版本使用来自其他主干版本的dll）
当我们进行发布构建时，我们有一个脚本遍历项目文件并将中继引用替换为组件的特定编号版本（从标记分支构建）
我认为这削弱了我们在开发过程中所做的测试，因为我实际工作的项目是使用不同的dll来发布版本将使用的。我希望始终针对组件的编号版本进行开发，并且只在有特殊需要时才更新它们。
然而团队中的其他人认为，除非我们针对主干进行开发（并且每个版本更新到组件的更新版本），否则我们将遇到以下问题：（a）我们的产品几乎不会更新到新版本的组件然后（b）当我们确实需要更新它将是一项艰巨的任务，因为组件源/接口将发生如此大的变化。
您遵循哪些做法？为什么？
编辑：对不起所有人，我刚刚意识到我有一些困惑的事情，提到有几个主要产品共享组件 - 虽然他们共享组件，他们不在同一台PC上运行。我关心的是这样的事实：因为组件可能随着产品的每次发布而变化（即使没有特定的更新组件的要求），测试会遗漏在组件中完成的一些微妙变化，而与组件无关正在对产品进行的具体工作。
答案 0 :(得分：10)
嗯，我可能在这里占少数，但这归结为释放管理。
根据定义，针对一组共享组件的trunk进行开发意味着组件是“移动目标” - 使用这些共享组件的开发人员不一定知道新发现的缺陷或失败是由于项目代码或共享组件，导致生产力下降，IMNSHO。
“共享组件”具有自己的发布周期。让您的其他开发人员休息并修复项目将要使用的共享组件的版本，并使用tags，labels或branches来标识共享组件版本。在项目的下一次迭代中，最新的共享组件的“稳定”或“生产”构建。
如果你原谅这个表达，那里还有另一种“气味”。项目发布之间的“源/接口将发生如此大的变化”的“共享组件”听起来像组件不是那么牢固或不一定要共享。
另请参阅此问题的答案Shared components throughout all projects, is there a better alternative than svn:externals?
答案 1 :(得分：3)
您应该拥有很少更改的强大接口，因此更改版本不应该那么难。
分离版本并针对特定版本进行操作会增加您需要更改的开销，但它也应该鼓励整体更少的界面更改，这将有助于长期。
答案 2 :(得分：2)
我们同时针对多个分支和主干进行开发，我们选择使用我们将推出到生产的代码来构建和测试每个分支。我不认为它是安全的。
基本上，如果开发人员正在使用trunk，他们所要做的就是担心从trunk构建并将代码提交到trunk。
任何在分支机构工作的开发人员都需要构建和测试该分支（有多个项目都分支/标记相同的构建/发布）。当他们提交对该分支的更改时，他们还必须将这些单独的更改合并到主干中。
我们希望所有开发人员都熟悉SCM（SVN）并能够维护多个代码分支。作为一个团队，我们处理重大的框架转换或巨大的代码更改，以最大限度地减少麻烦的合并。
答案 3 :(得分：2)
这里有两件事。首先，我认为你是对的;您希望针对最新的开发版本进行构建，而不是针对旧版本。如果你还没有，那么你将看到构建版本爆炸的情况，你必须彻底清理差异。
无论如何，我个人都是“提交主干，从分支发布”模式的粉丝。所有提交都进入主干，过夜构建或CI构建是针对主干的，人们可以自由地创建分支。如果您的行李箱符合验收标准，请标记候选发布版，但请保留更新到行李箱。如果你有一个很长的发布周期，那么你可能将更新版本n + 1添加到主干，但理想情况下你应该缩短你的发布周期。如果 对主干的更改不应该在已发布的版本中，并且您遇到需要更改的问题，请针对标记版本创建分支 ---并确保在实际发布后将任何更改合并回主干。
答案 4 :(得分：1)
我们正在使用scons构建系统，并在根目录中拥有我们自己的文件，该文件指定在构建应用程序时我们将使用的每个库的版本。
这减少了在您提到的几个位置更改版本名称的需要。
答案 5 :(得分：1)
（b）是否有效参数取决于共享组件的更改频率和更改频率。如果他们经常在您的工作场所发生变化，那么您“被迫”开发最新版本可能是有效的。这本身是否是一个问题是一个有效的问题。
但是，从您的角度来看，我没有看到如何在不对生产中使用的共享组件进行测试的情况下将代码推送到生产中。你是否针对发布版本进行了第二次测试？你只是祈祷没有什么破坏？坦率地说，（b）在这些情况下可以反过来支持你的观点：如果主干与最新的标记分支不同，那么必须付出努力以确保你的应用程序正常运行。
如果您的共享组件经常被标记，那么您的同事可能是正确的，并且管理从最新标记到主干的增量更改比管理任意版本X的更改更容易（在最后一个版本）到任意版本Y（当你选择升级时确定）。