Jan Schreuder on .Net

Increasing the build number is only done by the Build Server?

We have a daily build system at our current project. The build server increases the build number every day. When a developer does a local build on his workstation then it always has the buildnumber 9999. I personally don't like the local buildnumber of the fixed 9999. Would have been better if it would start at 10000 and increment for each build. This way you can more easily spot build dependancy errors.

I use subversion at home. Subversion has revision numbers for check-ins. My CI build system uses that number as the buildnumber.

This almost has the same effect as the daily build server and labels on source-safe.

You could say that we use the revision number for production patches at a version number branch.

The major/minor identify a branch in the repository and should match with a certian set of functionality or stability requirements.

I also like the linux versioning scheme:
http://en.wikipedia.org/wiki/Linux_kernel#Version_numbering

Which if quite relaxed to identify increments within a project and hotfixes on those increments. You would lose the buildnumber though so you should use something else to identify the build.

I agree with the major/minor/revision part of your versioning scheme.

But I would distinguish the file version from the assembly version, i.e., the AssemblyVersionAttribute and the AssemblyFileVersionAttribute. In the assembly version I keep the build number fixed at 0 to prevent problems with having to update strong named references that use the assembly version number for each build. In the file version the build number is set by the build server and increased after each build. For a local build by a developer a fixed build number can be used for the file version.

So increasing the major/minor/revision part of the version number is a conscious decision and might involve updating strong name references. Increasing the build number is done automatically. The build number in the file version is irrelevant for binding.

@Erwyn: Jups.. the assembly version is static in our builds. Didn't directly reflect is to .net but this is the case for our .net deliverables.

The file version is very important for installers! Installers only look at the major.minor.revision and ignore the buildnumber. If an installer sees that a dll with version 1.2.3(.2) is installed and you install another product with dll 1.2.3(6) then the installer ignores the .6 library.

I believe the way most java-guys do this makes pretty much sense to me:

A: complete new release
B: some public APIchanges have occured that might be breaking
C: some public API might have been added, not breaking.
D: no public API or breaking changes. only bugfixes inside the current API.

These guidelines make sense. We use the exact same protocol with the exception of the build number. The build numbers is increased for every nightly team- or cruisebuild to match the exact nr. of builds executed.