CODEWITHSUNDEEP
c#
ant2009
ant2009

Reputation: 22526

C# Effective way to manage revision number

C# 2008 SP1

I am wondering what is the best way to handle revision numbers.

I had always thought there is normally only 3 numbers. (Major, Minor, and Bug fixes).

However, I am left wondering what the build number is and the Revision number.

For example, in the past I have normally used only 3 numbers. I there is some very minor change or a bug fix I would increment the 3rd number (bug fixes).

Because I am new to this. What is normally done in the professional world?

Many thanks for any advice,

In my AssemblyInfo file I have the following:

// Version information for an assembly consists of the following four values:
//
//      Major Version
//      Minor Version 
//      Build Number
//      Revision
//
// You can specify all the values or you can default the Build and Revision Numbers 
// by using the '*' as shown below:
// [assembly: AssemblyVersion("1.0.*")]
[assembly: AssemblyVersion("1.0.2.*")]
[assembly: AssemblyFileVersion("1.0.0.0")]

// 1.0.2 Added feature for detecting if a sound card is installed.

Upvotes: 11

Views: 9775

Answers (6)

Paul Alexander
Paul Alexander

Reputation: 32367

You'll want to consider versioning your assembly and file differently. When you change the assembly version number it's possible, but extremely difficult, for existing code to use it without recompiling. We only change the assembly version when there are breaking changes so we can release minor bug fixes easily.

Read more on our Assembly Versioning policy.

Upvotes: 4

ant2009
ant2009

Reputation: 22526

Thanks for all your suggestions.

I have decided to use the following.

My project has the following version number: 1.0.2.20. 1. :Major changes 0. :Minor changes 2. :Bug fixes 20 :Subversion revision number

So I have changed the following in my assemblyinfo.c file

[assembly: AssemblyVersion("1.0.2.20")]

Any suggestions on this idea, I would be happy to hear.

Many thanks,

Upvotes: 1

Gerrie Schenck
Gerrie Schenck

Reputation: 22368

I think Paul Alexander's answer is the correct one but I'd like to add the following remark to your AssemblyInfo file:

If you use 1.0.2.* remember that the last bit (replaced by the *) is a random number So if you build 1.0.2.*` this evening, and you build it again tomorrow morning, the second version could have a lower version number than the build you did earlier.

Upvotes: 5

AnnaR
AnnaR

Reputation: 3186

We use the Bug-fix number in increments of two. Odd numbers mean released minor bug fixes and even numbers mean working on bug fixes. Apparently this is common in some businesses, i.e., the one I am in.

The idea is to identify accidental releases, and somehow I like the idea. Doing things so that you easily see things that are wrong. This does not say that an odd number necessarily is a non-accidental release, only that it is with a quite high probability.

Upvotes: 2

annakata
annakata

Reputation: 75844

From MSDN:

  • Build : A difference in build number represents a recompilation of the same source. This would be appropriate because of processor, platform, or compiler changes.

  • Revision : Assemblies with the same name, major, and minor version numbers but different revisions are intended to be fully interchangeable. This would be appropriate to fix a security hole in a previously released assembly.

Phil Haack has a nice deconstruction of the .NET versioning system, but in practice I don't think his concerns really matter since in my experience the .NET/MS versioning system is only really used by technical for debugging/support/tracking purposes, the public and project management will often be date or made-up-marketing-version-number based.

FWIW every .NET project I've worked on ha been governed by "X.Y.*" i.e. we like to manually control what the major and minors are but let the system control the build and revision.

Upvotes: 10

jrista
jrista

Reputation: 32960

Try this:

http://autobuildversion.codeplex.com/

Upvotes: 8

Related Questions