Question

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?

Answer 1

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.