views:

130

answers:

4

If your application has a public API that people develop against then what do you do in following scenarios?

  • If you publish service pack of your application do you change the version number of assemblies?

  • Similarly do you change the version number if you provide a hot fix?

If you do, do you provide policy files for assembly redirection? or if you don't where do the policy files fit in the scenario? When would I chose not to change the version number or provide a policy file and change the version?

+1  A: 

A reason to leave the version number unchanged is in relation with strong-named assemblies.

If you want to allow an already compiled application to use your updated strong-named assembly you may not change the version number as the application will require the same version of your assembly that it was compiled against.

This of course only holds if the assembly's interfaces are not modified.

0xA3
This is a real problem, and I understand the need to overcome it, but IMHO publisher policy assemblies are a much better way to deal with this problem. See http://msdn.microsoft.com/en-us/library/dz32563a.aspx
scott
@scott: This is probably true, but as far as I know Microsoft typically does not change the version number of their framework assemblies deployed to the GAC when applying a hotfix or service pack.
0xA3
Indeed, I believe they only change the file version. I think they advocate "do as I say, not as I do" :) We traded "DLL Hell" for "Version Hell".
scott
+2  A: 

We keep to the rule that the first three parts of the version number are more or less artificial numbers generated by marketing. The pattern is something like "Major.Minor.ServicePack". (The difference between a service pack and a hot fix is just politcs.) But the last number is auto inserted by the build script and keeps the last changed subverion revision of the branch the script is running on. By this we can always find the exact code base for any binary file "out in the wild".

Marc Wittke
A: 

The Microsoft way is to use Major.Minor.BuildNumber.Revision. I would suggest automatically generating and using the BuildNumber.Revision for Service Packs and Hot Fixes. I would manually modify and use the Minor build number for extensions to the API. I would manually modify and use the Major build number when changing things in a non-backward compatible way or introducing significant (30% or more) changes or extensions to the functionality.

Jeff Atwood actually has a blog post from back in the stone ages about version numbering and there is a question on here about automatically incrementing the version number and I like the answer that linked to Build Version Increment Add-In Visual Studio.

Larry Smithmier
+1  A: 

You only need to up the version number if the methods etc of the public api changed, or if the behaviour of a call changed such that a client might need to rewrite some of their code that uses your api.

Scott Langham