产品版本控制与语义版本控制

Question

以下情况：

• 一种由多个组件组成的产品，每个组件都有单独的版本(同一组件的所有手工艺品都有相同的版本)。
• POs指的是产品版本X和包含特定功能的X.a、X.b版本。
• 每个sprint都是一个新版本(可能安装在演示环境中)。
• sprint版本增加补丁版本，例如1.0.0，1.0.1
• 当我们在POs计划的下一个版本(例如X.a = 1.0和X.b = 1.1 )上开始开发时，次要版本将会增加。

我们开始了关于为组件引入语义版本控制(http://semver.org/)的讨论，但仍有一些疑问。

• 有些人发现，如果开发人员必须决定是否必须增加次要版本或补丁版本，就会变得更加复杂，并提出一些bug修复程序引入了新功能的观点(不要问)
• 一些人拒绝增加次要版本的想法，因为POs计划的发布可能还没有实现，也就是说，它还没有完成功能
• 使用当前的版本控制工程，根据版本是1.0.x还是1.1.x，可以很容易地看到哪些环境可能需要更新
• 在每次sprint之后，根据语义版本发布，我们将达到高主次版本，这也是因为一些好奇的客户检查版本而不喜欢的版本。

当涉及到scrum环境中的版本控制时，其他公司应用了哪些实践？在每次冲刺之后发布版本吗？你在哪里看到了你选择的方法的优点？

编辑:也许我的描述并不清楚，但组件版本与产品版本并不完全一致，两者之间唯一的关联是主要/次要版本增加的时间，例如：

• 产品1.0
  • 构成部分A 3.2
  • 构成部分B 4.5

• 产品1.1
  • 构成部分A 3.3
  • 构成部分B 4.6

• 产品2.0
  • 构成部分A 4.x
  • 构成部分B 5.x

我同意产品版本应该与技术版本无关--这是一个标签。这就是为什么我试图找出其他人是如何解决这个问题的，以及这些争论是什么。;)

Answer 1

一个简单的解决方案，不仅仅是对于敏捷团队，是将工程版本和营销版本分开。这方面的一个著名实例是微软对Windows NT的版本控制：

• 第一个版本是3.1，而不是1.0
• 销售版本Windows 2000，工程版本WindowsNT5.0 (MS决定停止开发基于DOS的版本，并因此从产品名称中删除NT，尽管同时发布了Windows ME )。
• 销售版本Windows，工程版本WindowsNT5.1
• 营销版Windows专业版x64，工程版WindowsNT5.2(有趣的是，AMD64端口有自己的版本号，而Windows 64位版，即IA64端口，没有)
• 销售版本Windows，工程版本WindowsNT6.0
• 营销版Windows 7，工程版WindowsNT6.1(实际上，工程版本最初是7.0版，但微软在兼容性测试中发现，很多软件都在测试major == 6是否启用后XP功能，微软并没有破坏所有这些应用，而是决定将主要版本恢复到6。在主题演讲期间，他们开玩笑说Windows 8会有6.1.1版本等等，原因也是如此)。
• 销售版本Windows 8，工程版本Windows NT 6.2
• 销售版Windows 8.1，工程版Windows NT 6.3
• 营销版本Windows 10，工程版本Windows 10.0 (微软重新调整营销和工程版本与Windows 10，但由于新的滚动发布模式，可以想象工程版本可能会改变，但营销版本保持不变)

请注意，微软也有发布号和单调增加的构建数，但在营销版本中都没有显示出来。

因此，在工程版本(在敏捷项目中可能会导致较高的版本号)中，您可以遵循SemVer，营销部门可以随意选择他们想要的版本控制方案。您可以将营销版本看作是一组功能的可读的短标签，而这些功能恰好被格式化为版本号。