计划不周、分支多、精神分裂的应用程序的版本号方案是什么 [英] What version number scheme for poorly planned, branched, and schizophrenic application

问题描述

我正在寻找一个应用程序的版本编号方案/模式/系统，该应用程序目前使用 贝壳游戏 风格的发布日期.这使得版本控制成为一场噩梦.我想只使用典型的 Major.Minor.Revision，但是这对我来说很快就会崩溃，就像目前在这里运行的方式一样.

I'm looking for a version numbering scheme/pattern/system for an application that is currently branched into several versions with shell game style release dates. This has made versioning a nightmare. I'd like to just use the typical Major.Minor.Revision however this will break down for me quickly the way things are presently run around here.

这是我的库存...

• 1.0.0 - 生产版本.
• 1.0.1 - 生产修订 版本，修复了错误.
• 1.1.0 - 生产 次要 版本，新功能将于 7 月到期(必须遵守法规).
• 1.2.0 - 生产次要版本，具有与not-yet-released-still-under-development集成的新功能系统A.
• 2.0.0 - 产品的开发主要版本2.0"(代码迁移到更新的平台，提高了可用性).

• 1.0.0 - Production version.
• 1.0.1 - Production revision version with bug fixes.
• 1.1.0 - Production minor version with new features due in July (regulations compliance, must be done).
• 1.2.0 - Production minor version with new features to integrate with not-yet-released-still-under-development System A.
• 2.0.0 - Development major version "2.0" of the product (code migrated to newer platform, usability improved).

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

And to make it more fun, they are planning another project (new features) for integration with a different system.

• 1.3.0 - 生产次要版本，具有与系统 B 集成的新功能.

• 1.3.0 - Production minor version with new features integrating with System B.

增加复杂性的事实是我们不知道这些将上线"的确切时间(阅读:顺序).如果我们正在集成的系统之一被延迟，那么管理层会更改发布时间表.因此，今天的 1.2.0 版本可能会延迟，然后我们标记为 1.3.0 的构建将首先下降.在周期结束时不更改版本标签，与 QA 协调已经够困难了.

Adding to the complexity is the fact that we don't know exactly when (read: the order in which) these will "go live". If one of the systems we are integrating with gets delayed, then management changes the release schedule. So version 1.2.0 today could get delayed and then the build we tagged as 1.3.0 would drop first. Coordinating with QA is difficult enough already without changing version labels at the end of the cycle.

有问题吗?想法?毛茸茸的小动物?

Questions? Thoughts? Small furry animals?

和平|露水

推荐答案

在我看来，您不想专门使用版本号.您可以使用代号，(Windows 在每个版本发布之前都这样做了).您基本上需要比数字更多的东西来区分内部您所谈论的分支.随着版本的发布，您可以在它们上面打上 Major.Minor.Revision 标记，但在那之前，您需要以易于识别的方式命名它们.

Sounds to me like you don't want to use version numbers specifically. You can use codenames, (Windows did this with each of their releases before they were released). You basically need something more than numbers to distinguish in house which branch you are talking about. As the versions are released you can slap a Major.Minor.Revision stamp on them, but until then you need to name them in a way that will be recognizable.

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

Split them into branches and sub-branches. Make sure that anything dependant on a higher branch has a derivative name. So, you could call a branch ProductionMac, and a branch ProductionWindows, and that way you would know instantly that they are not to be merged, and that they both derive from production.

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

The most important thing to maintain is the structural hierarchy. Version numbers do this fairly well, but you have to keep adding "." for each new layer, which is annoying and completely undescriptive (much like naming your variables variableOne,variableTwo,variableThree) So, make sure that however you choose to label each branch, it is still obvious which branches are related to which other branches.

这篇关于计划不周、分支多、精神分裂的应用程序的版本号方案是什么的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！