客户端应用和服务的单独版本号？

Question

假设您有一个产品，它包含多个客户端UI（桌面，Silverlight，iPhone），它们共享公共业务代码，WCF服务和单个数据库。所有源都在一个git存储库中。

是否应该独立构建和版本化每个UI部分和WCF服务，或者新构建是否应增加所有这些部分的版本号？

Answer 1

在我的脑海中，有许多不同的方法可以解决这个问题，而且没有一种方法是“正确的”。这完全取决于您的发布流程以及您希望如何向客户展示您的产品。

如果您以锁步方式测试和发布组件，那么让您的版本号同步移动也许很有用。这样每个人都知道桌面UI版本1.4.4知道1.4.4 iPhone版本应具有相同的功能。

如果您的UI可以在不同时间使用不同的功能（急于在桌面上发布功能，但它可以等待iPhone），那么显然您将拥有不同的版本号。但是，我建议主要版本应该将版本号重新同步到X.0.0。

您可以通过让产品遵循通常的<major>.<minor>.<maintenance-patch>部分的自己的版本计划，并将构建号作为最后一个组件包含在内，这有点没有用。所以你最终会得到<major>.<minor>.<patch>.<build>。这种方法的优点是您可以在不同的时间发布不同的组件，并且您仍然可以获得它来自的构建记录。在这种情况下，构建号应该是单调递增的数字，通常由集中构建系统管理。我通常不喜欢将版本号的控制权留给构建系统，因为在市场营销，产品线管理等方面可以有很多关于主题的敏感性。拥有构建号非常有用，但要使它最少版本号的重要部分。

我建议的一件事是让您的构建过程一次“构建世界”。显然，您需要为了方便开发人员而启用构建单独的UI，但是管理单个每晚构建流程要容易得多，这些流程可以一次性构建具有所有依赖关系的所有可能组件。并确保所有UI在存储库中使用相同的当前共享组件。如果他们需要不同版本的共享组件，那么当您尝试正确构建所有内容时，就会要求一个受伤的世界。然后，您最终会为各种组件创建单独的构建，从而触发UI的构建等。