客户端应用程序和服务的单独版本号？
假设您有一个由多个客户端 UI（桌面、silverlight、iPhone）组成的产品，它们都共享公共业务代码、WCF 服务和单个数据库。所有源都在一个 git 存储库中。
每个 UI 部分和 WCF 服务是否应该独立构建和版本控制，或者新的构建是否应该增加所有这些部分的版本号？
Let's say you have a product which consists of multiple client UI's (desktop, silverlight, iPhone) which all share common business code, WCF services and a single database. All the source is in a single git repository.
Should each of the UI pieces and the WCF services be built and versioned independently or should new builds increment the version number for all of them?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在我的脑海里，有很多不同的方法来处理这个问题，但没有一个是“正确的”。这完全取决于您的发布流程以及您希望如何向客户展示您的产品。
如果您同步测试和发布组件，那么让版本号也同步移动可能会很有用。这样每个人都知道 1.4.4 版本的桌面 UI 就知道 1.4.4 iPhone 版本应该具有相同的功能。
如果你的 UI 在不同时间可以有不同的功能（急于在桌面上发布某个功能，但可以等待 iPhone），那么显然你会有不同的版本号。不过，我建议主要版本应将版本号重新同步到 X.0.0。
您可以通过让产品遵循其自己的通常
.. ... 我建议的一件事是让您的构建过程一次性“构建世界”。显然，为了方便开发人员，您会希望启用构建单独的 UI，但管理单个夜间构建过程要容易得多，该过程一次构建所有可能的组件及其所有依赖项。并确保所有 UI 都使用存储库中相同的、当前的、共享的组件。如果他们需要不同版本的共享组件，那么当您尝试正确构建所有内容时，您就会遭受巨大的伤害。然后，您最终会对各个组件进行单独的构建，从而触发 UI 等的构建。
Off the top of my head, there are a number of different ways to handle this, and none of them are "right." It all depends on your release processes and how you want to present your product to the customer.
If you test and release your components in lockstep, it's probably useful to have your version numbers move in lockstep as well. That way everyone knows version 1.4.4 of the desktop UI knows that the 1.4.4 iPhone version should have the same features.
If your UIs can have different features at different times (rush to release a feature in the desktop, but it can wait for iPhone), then obviously you'll have different version numbers. I'd recommend, however, that major releases should re-sync up the version numbers to X.0.0.
You can make this somewhat moot by having the products follow their own version schedule for the usual
<major>.<minor>.<maintenance-patch>part, and include the build number as the last component. So you'd end up with<major>.<minor>.<patch>.<build>. The advantage to this approach is that you can release different components at different times, and you still get the record of the build it came from. In this case, the build number should be a monotonically increasing number, typically managed by a centralized build system. I usually don't like to leave control of version numbers to the build system, as there can be a lot of sensitivity around the subject with marketing, product line management, etc. Having the build number is very useful, but make it the least important part of the version number.One thing I will recommend is having your build process "build the world" at one time. Obviously you'll want to enable building the separate UIs for the convenience of developers, but it's a lot easier to manage a single nightly build processes that builds all the possible components with all of their dependencies in one shot. And make sure all the UIs are using the same, current, shared components in your repository. If they need different versions of shared components, you are asking for a world of hurt when you try to correctly build everything. You then end up having separate builds for the various components, which trigger builds of the UIs, etc.