如何在不混淆的情况下交付多个应用程序版本？答案

【问题标题】：How to deliver multiple application versions without confusion?如何在不混淆的情况下交付多个应用程序版本？
【发布时间】：2010-10-22 11:05:33
【问题描述】：

我们目前在我们的网络应用程序的多个分支上工作。选择的 VCS 是 SVN。

我们有：

v1：/trunk，实时应用，错误修复
v2：/branches/1，附加功能，没有主干错误修复

计划了更多步骤。目前的计划是有一个稳定且客户端接受的 v1，然后将 v2 合并到 v1 中。到时候肯定会弹出v3。

问题是客户需要更多的透明度，他目前只能看到和测试v1。如果我也向他们提供 v2，他们很可能无法区分版本并再次报告 v1（已修复）错误以用于 v2。这将是一团糟，imo。我也不喜欢每天合并的想法，因为它更难区分新旧错误。

我感觉这更多是我们开发过程的问题，而不是技术问题。欢迎大家对解决问题或让双方对未来发展感到更方便的任何启示。谢谢。

编辑

还有一个部分问题是我的同事对版本控制不太深入，使用 2 个分支对他们来说已经很不方便了。但是，如果我找到更好的策略，我可能会强迫他们做正确的事。

edit2

感谢大家的回答。经过一番思考，事实证明整个问题更大，因为我们将二进制文件保存在 SVN 中。如果没有非常严格的政策，合并将是不可能的，而且可能无论如何都会被削弱。

【问题讨论】：

“他们很可能无法区分版本” 为什么？没有横幅？没有日志？为什么他们不能区分版本？
我们目前不向最终用户显示当前版本。最重要的是，我们只有一条错误消息，给用户留下的印象是我们无法修复这个单一的错误。我正计划改进这一点，但你知道，截止日期之类的。

标签： svn deployment versioning

【解决方案1】：

“没有主干错误修正”
“要区分新的和旧的 bug 就更难了。”
“我感觉这更多是我们开发过程的问题，而不是技术问题。”

该死的直。您的开发过程未能确认 V1.1 中的故障。如果不将V1中的更正结转到V2，你怎么希望V2比V1好？！

错误修复总是比新功能更重要。如果旧功能已损坏且不值得修复，则删除它们。

摆脱你的懒惰；如果您或某人已努力修复 V1 中的缺陷，请确保它不会再次出现在 V2 中。修理它！如果您的代码太垃圾以至于每天都会发生这种情况，那么请停止在 V2 上工作，并专注于减少错误修复的频率。如果您无法使 V1 功能正常工作，那么您将永远无法进入 V3。

我可能还建议使用“mercurial”或“git”或“bazaar”而不是 svn。如果您找到并使用“樱桃采摘”和“队列”功能，它们会更好地控制管理类型：您可以添加一个功能并将 -ONE-that-management-think-will-save-save-them 投入生产没有拉扯他们提出的所有其他半生不熟的想法，然后就放弃了。如果政治阻止了向分布式版本控制的转变，那就自己使用它，并且只将你交付（和他们想要）的东西推送到 svn。

【讨论】：

这就是我们正在做的，我们首先在 v1 中修复错误并等待反馈。如果一切正常，我们就会推出。但是由于几个原因，客户尚未接受 v1 作为最终版本。与此同时，我们正在开发 v2。将 v1 合并到 v2 将是一种选择。
是的，我是说您应用于 v1 的任何修复都应该应用于 v2；无论客户端是否已签署部署它。或者在最终部署时应用修复
客户缺乏信心。我们已经实现了所有必需的功能，并且应用程序运行良好。从长远来看，未来会出现一些问题。但是这些问题是可控的，随着应用程序的发展和成熟，我们可以努力寻找解决方案。猜猜客户只是想要一个过于完美的 v1。

【解决方案2】：

这似乎有点杂乱无章。将版本 2 合并到版本 1 中？诶？你还剩下什么版本？还是版本 1？具有版本 2 的功能？什么..？

我喜欢小型项目：

Trunk：当开发人员确信它正在工作时，事情就会在这里提交。对主干进行内部 QA 测试。

标签：通过从主干复制，为每个版本制作一个新标签。将您的标签命名为“/tags/v1.0”或“/tags/v1.1”，或者您想这样做。如果您需要一个外部客户端 来测试某些东西，请将您的标签命名为“/tags/v1.0-beta”之类的名称并让他们进行测试。不要让他们用主干进行测试，因为在他们测试的同时你还在开发！

分支：当您有一个需要一些时间来开发的功能时，您不能在它完成之前将它提交到主干。做一个分支。以您正在实现的功能命名，例如“/branches/user_logins”。

错误修复被提交到主干并包含在下一个标记版本中。如果有一个必须在今天发布的紧急错误修复，但后备箱中还有一些尚未发布的内容，请制作另一个标签，但从错误版本的标签中复制而不是从后备箱中复制，将其命名为“v1.1”。 0.1"，修复那里的错误，给他们一个新版本，然后将该错误修复合并到主干中。

【讨论】：

【解决方案3】：

对我来说，您似乎切换了术语分支和主干。通常，主干是活跃的开发分支，其中发布存在于它们自己的错误修复分支上。看起来您将主干用作 release1 错误修复分支，而 /branches/1 是真正的开发主干，并且由于无法为 release2 创建第二个主干而被卡住。

如果我是对的，我建议将您当前的主干移至 /branches/v2 分支，将 /branches/1 分支移至 /trunk。在这种情况下，您可以根据需要拥有尽可能多的发布分支（但尽量保持它们尽可能低），而主要的开发线位于 /trunk 中。

请参阅http://nvie.com/posts/a-successful-git-branching-model/ 了解更多详情。虽然是针对 git 的，但是有很多独立于 VCS 的信息。

【讨论】：

【解决方案4】：

我同意你的其他海报。 c0rnh0li0 您需要重新考虑您的签入和合并政策。

查看您的存储库布局并尝试定义团队中的任何人都可以轻松重复的规则，并有助于填充从稳定到不稳定的更改。对我来说，这允许主要在一个方向上进行合并。

维护分支场景的示例布局

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 源

可能性：

如果是 web-projekt 主机，则 URL 上包含分支名称的版本
对于任何项目：只需签入包含“版本 3.x”之类的徽标或文本属性并将其显示在您的应用程序中
最酷的解决方案是使用 svn keywords 并在您的应用中解析 $HeadURL$ 的值，以动态显示此构建源自的分支名称

【讨论】：