计划不周、分支和精神分裂的应用程序的版本号方案

Posted 2023-03-05

【中文标题】计划不周、分支和精神分裂的应用程序的版本号方案

【英文标题】：What version number scheme for poorly planned, branched, and schizophrenic application

【发布时间】：2009-05-11 21:01:42

【问题描述】：

我正在为一个应用程序寻找一个版本编号方案/模式/系统，该应用程序当前分支为多个版本，具有shell game 样式的发布日期。这使版本控制成为一场噩梦。我想只使用典型的 Major.Minor.Revision 但这会像目前在这里运行的方式一样迅速对我造成影响。

这是我的库存...

1.0.0 - 生产版本。 1.0.1 - 带有错误修复的生产 revision 版本。 1.1.0 - 带有新功能的生产 次要 版本将于 7 月到期（必须遵守法规）。 1.2.0 - 生产 次要 版本，具有与 not-yet-released-still-under-development System A 集成的新功能。 2.0.0 - 开发产品的主要版本“2.0”（代码迁移到更新的平台，可用性得到改善）。

为了让它更有趣，他们正在计划另一个项目（新功能）以与不同的系统集成。

1.3.0 - 生产 次要 版本，具有与 System B 集成的新功能。

增加复杂性的是，我们不知道确切的时间（阅读：顺序）这些将“上线”。如果我们正在集成的其中一个系统出现延迟，则管理层会更改发布时间表。所以今天的 1.2.0 版本可能会延迟，然后我们标记为 1.3.0 的构建将首先下降。如果不在周期结束时更改版本标签，与 QA 协调已经很困难了。

问题？想法？毛茸茸的小动物？

和平|露水

【问题讨论】：

谢谢，我现在头疼；你在工作中一天喝多少酒？

很遗憾，我不喝酒。虽然这很可能是我一直在寻找的答案。

那是一场噩梦。也许您可以使用每个项目符号的代码名称，然后将修订号用于其中的补丁。只是一个想法。

对您组织的房子的诅咒。或者其他的东西。因为，现在我在想这个。我不确定我是否有足够的资源来处理实际工作和您的问题。为什么不是星期五？

【参考方案1】：

在我看来，您不想专门使用版本号。 您可以使用代号，（Windows 在发布之前对它们的每个版本都这样做了）。 你基本上需要比数字更多的东西来区分inhouse你在谈论哪个分支。随着版本的发布，您可以在它们上贴上 Major.Minor.Revision 标记，但在此之前，您需要以可识别的方式命名它们。

将它们拆分为分支和子分支。 确保任何依赖于更高分支的东西都有派生名称。 因此，您可以调用 ProductionMac 分支和 ProductionWindows 分支，这样您就可以立即知道它们不会被合并，并且它们都源自生产。

要维护的最重要的事情是结构层次结构。版本号可以很好地做到这一点，但您必须不断添加“。”对于每个新层，这很烦人且完全无法描述（很像命名变量 variableOne、variableTwo、variableThree）因此，请确保无论您选择如何标记每个分支，哪些分支与哪些其他分支相关仍然很明显。

【讨论】：

您可能会惊讶地发现这是一个 Web 应用程序。我知道我会的。

并不惊讶，我已经开发了（目前正在开发）一些具有多个分支的 Web 应用程序，这些应用程序具有多种用途，以适应多个老板和多种情况。

我已经为此努力了一段时间，我认为 devin 处于最佳轨道，因此 +1。就像“RabbitOfCaerbannog.Swallow.European.Newt”作为版本名称一样有趣，它并不是特别具有描述性......

每个版本在发布前都会有多个 Dev-to-QA 周期，因此我们的系统需要数字来进行顺序参考。因此，我可能在开发过程中拥有 ProductionMac.JulyCompliance.1 (.2, .3, .4)，但在我们发布时将版本 1.1.0（来自上图）放在上面。

确切地说，生产版本应该在major.minor.revision中进行数字标记。但这是基于 ACTUAL 版本，而不是 PROJECTED 版本。在实际发布某些东西之前，您可以使用代号。

【参考方案2】：

听起来数字没有多大帮助，我会用毛茸茸的小动物来命名这些版本。

或者，以生成它的项目命名每个版本（“UI 大修”、“6 月维护”等），然后只在它上线时为其分配一个版本号？

【讨论】：

我同意。等到发布时间，然后给它一个数字。

感谢您的投票，但我认为 devinb 的答案可能会更好——分层代号。

是的，我认为您对 devonb 的看法是正确的。感谢您的努力！

【参考方案3】：

我会使用字典在内部开发编号和外部“发布”编号之间进行映射，然后在内部使用内部开发编号，并且仅在您准备将其从开发中发布时才公开“发布”编号。

如果您使用使用无理数的中间地图，则会获得奖励积分。 “版本 3.14159 的开发进展如何？” “哦，不错，但我仍在修复我们在 2.71828183 版本中发现的错误。” “什么？那个bug？应该在次要版本1.73205中修复！” :-)

【讨论】：

很好......为什么不把它提升到一个新的水平并使用虚数：“嘿，build (5 + 2j) 怎么样？

评论 +1 说实话。

顺便说一句，3.14159 并非不合理。

【参考方案4】：

正如其他人所建议的，在内部使用非数字代号，并在每个组件发布时应用一个数字。

在版本控制中附加修订/内部版本号可以帮助您将此内部代号与外部版本号匹配（并有助于与 QA 沟通）。

例如： 法规遵从性 r1234 对应于版本 1.1.0.1234。

【参考方案5】：

根据您的描述，我同意前几篇文章。与范围/功能集相关的有意义的、唯一的名称可能是每个分支的方式。每个命名分支中的编号版本似乎是合理的。

您真正需要...是 Gmail 样式的标签...用于您的版本控制！

【参考方案6】：

nth-ing 以前的帖子。

我们的构建系统在每次构建之后（无论是否发布）都会增加构建号，这是开发/质量检查用来识别构建的。最终版本 # 仅在 QA 发布时向外界公开。所以确实有多个 1.3.0.x 版本，但只有一个真正的 1.3.0。

【参考方案7】：

这是我昨天在讨论这个问题时考虑的另一种选择。也许我需要重新考虑什么是major。与另一个系统集成可能是少量工作，但如果它以如此重要的方式影响调度和发布日期和版本，就像它在这里对我所做的那样，也许仅此一项就足以将分支提升到主要状态。这样我的一些头痛就会减轻。

无序发布版本的最可能场景围绕着次要迭代。 主要的需要跨部门的协调努力。你可以在地平线上看到它们。 minor 偷偷靠近你，把一切都搞砸了。

“这是新的合规性 法规。如果他们不去生活 7月15日，我们将被罚款50万美元。 每天。”

“什么？你什么时候得到这些的？”

“去年 7 月。你不是在 分布？”

** 捂脸**

我仍然认为德文布的答案是最好的。但我想把这个扔在这里给其他处于困境的人。

和平|露水