我们正在接近我们公司新产品的初始版本，我正在尝试确定管理所有不同组件版本的最佳方法，并将这些组件与我们软件的营销部门版本进行交叉引用。由于各种原因，营销部门已确定我们产品的初始版本为 10.1，但所有组件最初都将从 1.0.0 开始。通过正常的 bug 修复和补丁以及持续的开发工作，不同的组件将不再具有相同的版本号，所以当市场部决定是 10.2 版本时，它可能包含 1.1.54、1.2.32、1.8.2、等等。显然，我可以使用一个简单的电子表格，但这并不是最用户友好的方法，
是否有更“专业”的方法，或者简单的电子表格是最佳选择？
我建议的主要原则是：尽可能使用最简单的方案。
考虑为您自己、您的营销部门和您的用户简化事情。
当你发布一个版本时，增加主要/次要版本号，然后在你的所有组件上标记它。所以在 10.1 版本中，所有程序集的版本号都是 10.1.xx.yy
然后，如果您真的想在一个版本中使用不同版本使问题复杂化（例如，对于较小的补丁/更新、不同的客户变体，或者只是用于内部日常或 CI 构建），那么使用 xx.yy 字段。（例如，在许多情况下，您可以让编译器使用编译日期/时间自动填充这两个字段）。
这意味着您有一个有意义的“营销版本”，它实际上与您的代码版本相关联（因此您和营销人员可以讨论特定版本而不会产生任何混淆），并且您可以添加额外信息（例如构建日期）如果（并且仅当）在开发方面需要。
编辑：PS 即使一个组件没有改变，用新的版本号重建它。试图跟踪一百个不同步的版本号是可以避免的噩梦。
为什么不保留所有组件的“随机”版本号，并创建一个包含所有组件的营销版本的超级标签/标签？这允许您在营销构建之间不断更新组件并增加其构建版本（无需转到客户可能可见的 10.1.001、10.1.002）并跟踪营销构建。此外，如果您为下一个营销构建更新了一些组件，而不是其他组件，会发生什么？您是否需要构建这些组件只是为了更新版本号？
根据您的源代码控制系统，您应该能够轻松创建具有指定名称/版本的版本，其中包含不同版本的所有这些组件。
您还应该只需要使用营销内部版本号更新一个属性文件，以便它显示在所有关于屏幕、启动屏幕、工具栏等的信息上。如果您没有这样的配置，您可能想要移动到这样一个系统。这允许轻松更改客户可见编号，同时保留所有组件构建编号。此外，当营销部门确定下一个版本不是 10.2 而是“Crimson”时会发生什么？
在我工作过的地方，我们会强制软件版本号与官方的公开（即市场营销）版本号相匹配：如果他们想要发布“10.1”，那么这就是我们将软件的版本资源设置为，作为发布版本的一部分。