如何交付多个应用程序版本而不产生混淆?

1. “没有中继错误修复”
2. “区分新旧虫子会更加困难。”
3. “我觉得这与其说是技术问题,不如说是我们开发过程中的问题。”

错误修复是 比新功能更重要。如果旧功能已损坏,不值得修复,则 移除它们 .

我也可以建议“mercurial”或“git”或“bazaar”而不是svn。如果你发现并使用“樱桃采摘”和“排队”功能,他们就更善于控制管理类型:你可以添加一个功能,并将管理层认为可以将其保存到生产中的功能拉出来,而不必拉去他们提出的所有其他半生不熟的想法,然后放弃。如果政治因素阻止了向分布式版本控制的转移,那就自己使用它,只把你交付的(他们想要的)东西推给svn。

好像没什么组织。将版本2合并到版本1?嗯?你还剩下什么版本?还是版本1?有版本2的功能吗?什么。。?

我喜欢小型项目:

Trunk:当开发人员确信它在工作时,事情就在这里被提交。对后备箱进行内部质量保证测试。

外部客户端 要测试某些东西,请将标签命名为“/tags/v1.0-beta”,并将其交给测试人员。不要让他们用后备箱来测试,因为当他们测试的时候,你还在开发!

分支:当你有一个需要花一些时间来开发的特性时,你不能在它完成之前将它提交给主干。做一根树枝。以您正在实现的功能命名,例如“/branches/user\u logins”。

错误修复将提交到主干,并包含在下一个标记的版本中。如果有一个紧急的错误修复必须在今天发布,但在主干中有一些东西还不能发布,制作另一个标签,但从错误发布的标签而不是从主干复制,称之为“v1.0.1”,修复那里的错误,给他们一个新的版本,然后将该错误修复合并到主干中。

对我来说,你好像换了分支和主干的术语。正常情况下,trunk是活动的开发分支,在那里发布的版本依赖于它们自己的bug修复分支。看起来您使用trunk作为release1 bugfix分支,而/branchs/1是真正的开发主干,并且由于无法为release2创建第二个主干而陷入困境。

如果我是对的,我建议将您当前的主干移动到a/branchs/v2分支,将您的/branchs/1分支移动到/trunk。在这个场景中,您可以根据需要拥有尽可能多的发布分支(但是尽量保持它们尽可能低),而主开发线在/trunk中。

见 http://nvie.com/posts/a-successful-git-branching-model/ 更多细节。虽然是针对git的,但有很多与风投无关的信息。

查看您的存储库布局,并尝试定义规则,这些规则很容易被团队中的任何人重复,并且有助于填充从稳定到不稳定的更改。对我来说,这允许合并主要在一个方向。

branches/v1
-approved and shipped/deploy
-Only bugfixes allowed

branches/v2
-is not approved by the client but nearly ready
-Fixes and feature-commits allowed that focus on getting v2 stable & ready
-receive bugfixes commited in v1 (merge down)

branches/v3
-is not approved by the client and far from ready
-Fixes and feature-commits allowed that focus on getting v3 stable & ready
-receive bugfixes commited in v2 (merge down)

trunk
-All syntax-error free commits allowed (mainline)
-receive merges from LATEST stable branch (merge down from v3 in this case)

最上面的分支是最古老的,功能最少,但是稳定性很高(经过测试,在最近的过去没有添加很多功能)。另一方面,躯干是相当不稳定和接受出血边缘的特点。v2和v3介于两者之间。 你也可以在树干的“下面”加上羽毛状的树枝,这比树干更不稳定。合并方向保持不变。我想引用一句咒语“合并,复制”。

准备/维护的并发版本越多,需要进行的合并就越多。但是,由于合并跟踪,它并不是一个任务,它可以确保不留下任何错误修复,必须重新发现并手动修复。

现在,虽然这将很大程度上修复您的变更流管理,并有助于将高风险开发与低风险隔离开来,但仍然存在将客户正在测试/预览的内容可视化的问题。

将应用程序VCS源可视化到客户端

可能性:

• 对于任何项目:只需签入包含“3.x版”之类内容的徽标或文本属性,并将其显示在应用程序中
• keywords 并分析应用程序中$HeadURL$的值,以动态显示此生成源于的分支名称