views:

135

answers:

1

We are developing an application with components on multiple physical tiers, sharing many assemblies as well as having some exclusive to each tier.

I am wanting to know what the typical versioning strategy is for release hot-fixes, or only a few components of the application.

Our issue tracking software contains a version number for the entire product. If the current version is 1.4.5 and a hotfix is required, the issues for the hotfix are to be released against 1.4.6. All assemblies affected by the fixes for 1.4.6 are versioned 1.4.6. If we distributed just those files we end up with some files on version 1.4.5 and some on 1.4.6.

A solution could be to rebuild and release the entire application as 1.4.6 but this would required multiple components on the multiple machines to be redeployed and result in unnecessary downtime of the components that didn't actually change.

What strategies have people put in place for this issue? Is it just a matter accepting that some files will have different version numbers? In the past I have found that this causes confusion with the customers (level 1) support team.

+2  A: 

You pose an interesting question.

It's really a policy decision that you need to make to decide what your deployment and versioning strategy will be, and consider the trade-offs of various factors (some of which you have already noted, such as customer confusion).

One of the things you could do is to decouple the release and versioning of your individual tiers, which would allow you to have consistent versioning within a tier with reduced hotfix deployment overhead. You would also need to factor out the common assemblies into a separate package and version that independently too.

This might be overkill, so an alternative would be to make your versioning easier to grasp. For instance, you could reserve a part of your version number to indicate hotfixes. For example, if 1.4.5.0 is the official release, the hotfix would be 1.4.5.1 and this can be easily understood to be part of the 1.4.5 official release.

You can also use other assembly versions, such as the AssemblyInformationalVersion to store version information for your users. (Check out my blog post for more details on AssemblyInformationalVersion and assembly versioning in .NET.)

Daniel Fortunov
Thanks Daniel. I am leaning toward releasing the entire application whenever a change in any of the tiers occurs. 99% of changes will be in the server components, so realistically downtime during updates is basically unavoidable.
rob_g
For the "official release" scenario this is probably the best approach. For the "patch" scenario, however, your downtime (and risk) would be reduced if you release only the components that need to be patched, to only the affected tiers.
Daniel Fortunov