同时版本编号
这个问题混合了一些项目管理和开发的内容。我了解项目版本编号的[主要].[次要].[补丁]计划。在我客户的项目中，我主要将这些编号用于内部目的，因此团队可以说“v1.3.2 的进度如何？”，而不是通过所涉及的功能来引用项目。
然而，有时我们的客户会同时发布多个小版本。每个次要版本都包含一组独立的功能（与客户公司的不同部门合作），但两者可能会在不同的时间发布。因此，如果我们将它们标记为 v1.3.3 和 v1.3.4，则 v1.3.4 版本可能会早于 v1.3.3 发布，然后整个命名方案无效。
如果您不知道哪个将首先发布（由于等待客户批准或其他外部调度冲突），您如何在内部参考这些不同的构建？
谢谢！
This question mixes a bit of project management as well as development. I understand the [major].[minor].[patch] scheming for version numbering of a project. With my clients' projects I use these numbering primarily for internal purposes so instead of refering to a project by the features involved, the team can say "what is the progress of v1.3.2?".
However, sometimes our clients have multiple minor releases at once. Each minor release contains a set of independent features (working with different departments of the client company), but both could launch different times. So if we label them as v1.3.3 and v1.3.4, the v1.3.4 version could release earlier than v1.3.3 and then the whole naming scheme is invalid.
How do you refer internally to these various builds if you don't know which will release first (due to waiting for client approval, or other external scheduling conflicts)?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
非常简单——我们在发布之前不会分配版本号。问题解决了！
这听起来可能很轻率，但这是事实。当然，我们会有名为“v5.5”的内部项目，但这些项目是独立于 v5.4.x 下一个迭代的当前工作的，只有在完成和发布后才会收到下一个“x”值。当 v5.5 准备就绪时，5.4 的工作就会停止，我们将对 5.4 所做的任何更改合并到 5.5 中，然后发布 5.5.0。
如果您为不同的客户（在您的情况下为部门）有单独的版本，则可以采用修改后的版本控制方案。我们所做的是使用[major].[minor].[client].[patch]，例如5.4.client1.4。 [补丁]将是独立的，仅对特定客户端有意义，而[主要].[次要]将对应于我们从中分叉的主代码库的[主要].[次要]版本。例如，我们可能同时在 5.5、5.4.x 和 5.4.client1.x 上工作。当 5.5 准备就绪时，5.4.x 会合并到其中，然后两个项目都合并到 5.5.x 中，但客户端项目可能还没有准备好合并所有这些更改，因此它将保留 5.4.client1.x 直到它被启动- 最新版本为 5.5，然后变为 5.5.client1.x。
这听起来可能令人困惑，但实际上对我们来说非常有效。我们之前采用了此方案的变体，其中客户端名称附加到完整的版本号，即 [major].[minor].[patch]_[client]；然而，[major].[minor] 再次对应于它被分叉/最后合并的“核心”[major].[minor]，并且 [patch] 完全独立于其他版本，并且仅对其有意义客户端（这就是为什么我们后来交换了[客户端]和[补丁]的相对位置，以明确例如5.4.7实际上可能比5.4.12.client1有更多修复/更“当前”，并且更好 当然，
当特定于客户的项目合并回来时，您可以将其删除并增量到下一个[补丁]，或者可能跳转到下一个[次要]甚至[主要]版本，具体取决于 客户项目合并到 5.4.x 项目，然后我们从该版本 6.0 发布，然后记得将内部 5.5 项目重命名为 6.1 时，这偶尔会导致一些暂时的混乱，但它仍然有效。
当 您环境的替代方案，在内部仅通过客户（部门）名称引用您当前的项目，例如会计项目、人力资源项目等。不要在内部使用此类事物的版本号，因为正如您所看到的那样导致混乱，例如版本 5.4.6 在 5.4.7 之后但在 5.4.9 之前发布；与此同时，5.4.8 从未发布，因为它已被取消。那只是一团糟，所以远离它。只需按客户名称调用您的项目，然后分配下一个号码
Pretty simple -- we don't assign version numbers until we release. Problem solved!
That may sound flippant, but it's the truth. Sure, we would have internal projects dubbed e.g. "v5.5", but those were separate and independent from current work on the next iteration of v5.4.x, which would receive the next value of 'x' only upon completion and release. When v5.5 is ready, work on 5.4 ceases, we merge any changes made to 5.4 into 5.5, and then we release 5.5.0.
If you have separate builds for different clients (departments in your case), you can employ a modified versioning scheme. What we did is use [major].[minor].[client].[patch], e.g. 5.4.client1.4. The [patch] would be independent and only meaningful to that particular client, whereas [major].[minor] would correspond to the [major].[minor] version of the main codebase from which we forked off. For example, we might have simultaneous work on 5.5, 5.4.x, and 5.4.client1.x. When 5.5 is ready, 5.4.x merges into that, and then both projects fold into 5.5.x, but the client project might not be ready to merge all those changes and thus it would remain 5.4.client1.x until it was brought up-to-date with 5.5, then becoming 5.5.client1.x.
This may sound confusing, but it actually worked very well for us. We previously employed a variation of this scheme, where the client name was appended to the complete version number, i.e. [major].[minor].[patch]_[client]; again, however, [major].[minor] corresponds to the "core" [major].[minor] from whence it was forked/last merged, and the [patch] is wholly independent from the other versions and only meaningful to that client (this is why we later swapped the relative positions of [client] and [patch], to make it clear that e.g. 5.4.7 might actually have more fixes/be more "current" than 5.4.12.client1, and to better communicate that independence.
When a client-specific project merges back, of course, you drop it and increment to the next [patch], or perhaps make the jump up to the next [minor] or even [major] version, depending on the nature of the work. This does occasionally lead to some temporary confusion when a client project merges into the 5.4.x project and then we release from that version 6.0, then remember to rename the internal 5.5 project to 6.1, but it worked nonetheless.
As an alternative for your environment, internally refer to your current projects simply by client (department) name, e.g. the Accounting project, the HR project, etc. Don't use version numbers internally for this kind of thing, because as you see it just leads to confusion like version 5.4.6 coming out after 5.4.7 but before 5.4.9; meanwhile 5.4.8 never gets released because it was canceled. That's just a mess, so stay away from that. Simply call your projects by client name, and assign the next number