1

注意：我是版本编号的新手。请原谅我的无知。

我有一个项目，其中尝试的主要版本（版本 B）被放弃，然后重新尝试并发布（版本 C）。每个版本都与以前的版本相比有重大变化，我不会认为是次要更新。B 版几乎没有进入 C 版。

版本 A (1.0)

  • 开发、发布、更新等

B版（？？？）

  • 开发、暂停、废弃。

版本 C (2.0)

  • 开发、发布、更新等

我觉得我应该有这样的版本，但担心丢失版本的混淆：

  • 版本 A (1.0)
  • 版本 B (2.0)
  • 版本 C (3.0)
4

4 回答 4

3

您应该有两个版本控制方案。一个内部的，遵循典型的形式：

major.minor.build.revision

然后是面向公众的。使用面向公众的版本，您可以将内部版本映射到“客户友好”的命名版本。就像围绕 Java 命名策略的欢闹一样。

于 2010-06-17T02:08:24.727 回答
2

我不介意缺少版本号，除非它是一场营销噩梦。从开发的角度来看，它只是一个指针，一旦你超过了某个点，以前的版本就只能作为构建未来版本的教训。就像你说的 - 版本 B 几乎没有进入版本 C，所以在内部承认版本 B 的存在有什么意义？

营销 - 有很多公司会跳过版本号。如果客户感到困惑，只需告诉他们您在改进产品方面取得了如此大的进步，您跳过了整个版本。另一方面，有时客户会觉得，如果他们收到 2.9 版的软件包，他们就有权免费获得 3.0 版的副本。毕竟 - 它紧随 2.9。通过 4.0 的命名约定阻止他们并为您的辛勤工作多花点钱。

这也将有助于宣布您的 EOL，允许您将不存在的版本 EOL 和之前的版本让您听起来像是王子，因为您使用新 EOL 版本的软件看起来像他们已经是一个版本离开。

这是一场智力游戏——你只需要在你的对手之前控制俄罗斯和中国。这就是他们称之为Risk的原因。

于 2010-06-17T02:13:21.470 回答
1

多点版本编号是浪费时间。吻。从版本 1 开始，以 1 递增，并坚持使用整数。如果您使用的系统强制使用额外的句点和数字，请忽略它们。保留每个版本的具体内容、发布时间、发布对象等的良好日志。任何人只根据版本号而不是“什么是新的”文档来决定是否升级不是任何人都需要关注的关于。

于 2010-06-19T02:59:26.870 回答
0

如果版本 B 从未发布，那么您的版本 C 可以以 2.0 的公开发布号发布。您不必承认有没有成功的内部版本。只要您跟踪映射，您的内部版本号不必与您的公开版本号匹配。

于 2010-06-17T02:24:24.113 回答