<< Log4Net Troubleshooting | Home | Tag Your Database - A Data Dic... >>

Which Version of Version?

As developers, I think we tend to take the definition of Version for granted. What are the components of a version? Well that's easy, it is:

Major.Minor.Build.Revision

Where the Build and Revision numbers are optional. At least that is the definition given my the MSDN documentation for the Version class.

But look up Version in Wikipedia and you get a different answer.

The most common software versioning scheme is a scheme in which different major releases of the software each receive a unique numerical identifier. This is typically expressed as three numbers, separated by periods, such as version 2.4.13. One very commonly followed structure for these numbers is:

major.minor[.revision[.build]]

or

major.minor[.maintenance[.build]]

Notice that this scheme differs from the Microsoft scheme in that it places the build number at the very end, rather than the revision number.

Other versioning schemes such as the Unicode Standard and Solaris/Linux figure that three components is enough for a version with Major, Minor, and Update (for Unicode Standard) or Micro (for Solaris/Linux).

According to the MSDN documentation, the build number represents a recompilation of the same source, so it seems to me that it belongs at the end of the version, as it is the least significant element.

In Subtext, we roughly view the version as follows, though it is not set in stone:

Major: Major update. If a library assembly, probably not backwards compatible with older clients. This would include major changes. Most likely will include database schema changes and interface changes.
Minor: Minor change, may introduce new features, but backwards compatibility is mostly retained. Likely will include schema changes.
Revision: Minor bug fixes, no significant new features implemented, though a few small improvements may be included. May include a schema change.
Build: A recompilation of the code in progress towards a revision. No schema changes.

Internally, we may have schema changes between build increments, but when we are prepared to release, a schema change between releases would require a revision (or higher) increment.

I know some developers like to embed the date and counter in the build number. For example, 20060927002 would represent compilation #2 on September 27, 2006.

What versioning schemes are you fans of and why?

What others have said

Chris Martin Sep 27, 2006 9:08 PM

# re: Which Version of Version?

It's funny that you posted this. We just got through talking about this very issue.

After mulling it over for awhile, we decided that we would use Major.Minor.yyddmm.autoIncrementRevision. I can't give you a reason for it though. ;) It wasn't MY decision.

Haacked Sep 27, 2006 9:13 PM

# re: Which Version of Version?

Well there's really no right decision. The important thing is to be explicit and pick a scheme and then stick to it.

Although I would recommend trying to stick with established conventions for Major and Minor at the very least.

vikram Sep 27, 2006 10:19 PM

# re: Which Version of Version?

Very interesting post for a developer like me

Ken Sep 27, 2006 11:13 PM

# re: Which Version of Version?

I've always been fond of major.minor.date.build. So, it could be 1.2.60927.456. That would mean v1.2 as the official label of the program, 60927 for the date (Sept 27th, 2006) and build number 456 from the build server (update the version tags last, and check it in with current build+1).

I like it because it incorporates the two different key ways I can easily identify multiple builds of the same product release, such as a v1.2 beta1 vs. beta2. Most of the time, I remember it by the date. But the build number often rings a bell, and it allows me to track exactly what changes were made between that build and another build (either newer or older).

Eric D. Burdo Sep 28, 2006 5:24 AM

# re: Which Version of Version?

One place I worked used to use:

5.3.<auto-increment>

Where 5 was the year, 3 was the version, and the third was the auto-increment value.

Yet another project used:

1.2.3.<auto-number>

And we had a custom launcher for the app. If Minor changed, we just copied over a new version of the app (for updating). If Major changed, we re-ran the setup. This was before ClickOnce, and was for in-house use.

Right now, I usually use Major.Minor.Build

Grim Sep 28, 2006 6:15 AM

# re: Which Version of Version?

My understanding is that if multiple versions of a library are in the GAC, any .Net application that uses that library will "auto-upgrade" to the highest version _with the same major.minor combination_

So I would say that if you're ever going to break backwards compatibility, you should always change either major or minor (or both.)

Lately I've gotten to where I do major.minor.* for the assembly version, and major.minor.yymmdd.sequence for the file version when building for release into QA and/or production.

Brandon Sep 28, 2006 8:16 AM

# re: Which Version of Version?

Personally I like incrementing the Major by 1 on any Production Release that was due to a full Project timeline. Then increment the Minor for each version between the Majors that fixed minor bugs not packaged in the Major Production release. Finally using the Revision increment with every time that the application has been compiled. This seems to help us a lot in marking the code within our code repository.

Major.Minor.Revision (i.e. 5.1.13)

Brandon

Adam Sep 28, 2006 9:51 AM

# re: Which Version of Version?

"My understanding is that if multiple versions of a library are in the GAC, any .Net application that uses that library will "auto-upgrade" to the highest version _with the same major.minor combination_"

That's a throwback to the early betas of 1.0. I don't actually think it was ever implemented, only talked about then eventually discarded instead for publisher policy.

Where I work, for assemblies we use the first number to indicate huge breaking change, the second to indicate non-breaking changes but a significant release, the third and fourth numbers to represent minor patch-style bug fixes.

For our product we let Marketing decide the first two numbers, we pick the third number based on which release it is (0 for the first GA, 1+ for service packs and updates) and the fourth numbers gets incremented for every explicit build (so our latest product installer version is 5.2.1.301).

Joshua Flanagan Sep 28, 2006 3:37 PM

# re: Which Version of Version?

Ken and anyone else using a 6 digit date build number: keep in mind, if you are using this scheme with .NET assembly versions, you WILL get caught by a "Y2K7" issue. Meaning, in about 3 months, your builds will break ;)

Each component of a .NET version is an unsigned 16 bit integer, which means it will max out at 65535. As soon as the "6" flips to "7", you will get a compiler error.

Mike Bouck Sep 29, 2006 7:56 AM

# re: Which Version of Version?

Joshua, the way we get around that one is we use "0" to represent the project's "starting year". You then increment your starting year in subsequent years by the first digit in the revision number. So we might have:

1.0.0929.3 (3rd build of 1.0 built on 09/29/06).
1.0.10101.2 (2nd build of 1.0 built on 01/01/07).

Granted, this only buys you about 6 or so years worth of builds but that is a lifetime in most cases and hopefully Microsoft has fixed this issue by then! The other thing this scheme buys you is an always increasing revision number which becomes important for things like ClickOnce.

Joshua Flanagan Sep 29, 2006 7:10 PM

# re: Which Version of Version?

Sure, that will work. There is also Clemens' BuildDay algorithm that uses the last digit of the year (6), and then a 3 digit number indicating the day of of the year (today is the 272nd day of the year) = 6272. I'm not saying all date-based builds will break, just this particular one.

Also - I'm not sure MSFT would consider it an "issue" to be fixed. The assembly version that is part of an assembly's identity is a 64 bit integer. It breaks up neatly into 4 groups of 16 bits for convenience. There is nothing necessarily wrong with that.

AC [MVP MCMS] Oct 01, 2006 6:15 AM

# re: Which Version of Version?

I prefer the MAJOR.MINOR.BUILDDATE.build number. I use the MSBuild AssemblyInfoTask custom task for MSBuild o share my automatically manage the date in my versioning which you can get here: http://blogs.msdn.com/msbuild/archive/2005/12/07/501180.aspx

DotNetKicks.com Oct 03, 2006 6:00 PM

# Which Version of Version?

Trackback from DotNetKicks.com

Trumpi Oct 04, 2006 12:35 AM

# re: Which Version of Version?

If you use a source control tool like Subversion, it is a good idea to keep the revision number somewhere in the version. That way you are able to track and reproduce issues that occur outside of the development team because the version of your executables are unambiguously linked to a version of your source code.

gm Oct 04, 2006 12:07 PM

# re: Which Version of Version?

Why cares? The versioning scheme should match the development process that uses it.

Dan's Archive Oct 11, 2006 6:58 AM

# New and Notable Links : Sep 27 - Oct 10 2006

Jonas Feb 17, 2007 4:52 AM

# re: Which Version of Version?

What most version number scheme immediately, and conviniently, forget is the murky depths of maintenance where branches are born and grow into tangling webs of versions.
I'm very much in favor of having the two first digits "mean" something, especially for compatibility, but I wouldn't put any stop to how many milli, micro, nano version points to have after that. Although they don't say anything special they tell me (i.e. developers) how this version came to be and what to expect or not bugfix wise.

Medi Montaseri May 13, 2007 10:43 PM

# re: Which Version of Version?

I like the four component versioning scheme like
major.minor.releaseCandidate.release or xx.xx.xx.xx

Basically major.minor is in the bag....mostly agreed on
The other two I like for the following reason.

Since typical software dev cycle includes development, Integration test and QA test, we can reserve major and minor for developers. So dev will deliver
xx.xx.01.00 to Integration Testing as release candidate 01. This instance of the code is either rejected or passed. If rejected, it goes back to dev and come out as xx.xx.02.00 and the cycle continues until xx.xx.53.00 where Integration Testing finally OK the release and the product moves forward to QA. Note that while the 3rd number is 00, it means this code is in alpha stage. And as long as the 4th number is 00 it means in beta stage. Finally the product is delivered to QA as xx.xx.53.01. QA will take a shot at the product and finally validates xx.xx.53.17

along the way the src is tagged with xx_xx_xx_xx as we go.

Here is an interesting ROI from this scheme...If I have a product that reads xx.xx.87.12 it means that Integration Testing failed the code for 87 iterations which means lots of QA upstream and it shows that the eng dept is just throwing the code over the fence without really developing good product.

now onsider a product with a version like xx.xx.12.87 this means that eng just throw over the product and said its done , Integration guys were just browsing the net and saying yep..it works and finally the QA guys failed the product 87 times....

The only problem with this scheme is that it is a wistle blower and could cause tention in a politically charged company...

So I like the xx.xx.xx.xx format and that was why...

Seba Apr 17, 2008 7:44 PM

# re: Which Version of Version?

Hi,

We use mayor.minor.edit.patch. The problem we have faced now is to implement or not a diferent versioning for the client and server. Sometimes we only update the server, so increment the server patch number, but not the client. everytime the client need to be updated, we also incrment the server, because the server serves the client installer.

Best wishes!

ricko Jan 07, 2009 12:52 PM

# re: Which Version of Version?

Don't forget that the version number system you use has to work with the tools you use.
For instance, WIndows installer ignores the third and fourth place in the version when comparing newness of files, assemblies.

Sean Feb 24, 2009 9:15 PM

# re: Which Version of Version?

i am a fan of major.minor.update.release-date
for example v3.20.10.090225 (feb 25 of 2009)
and i make each update worth about at lest 7 to 10 changes to the code for example rewiriting a code block or fixing a minor bug and when i have made 100 updates i move the minor number up one so if v1.0.x reaches v1.00.99 the next would be v1.01.00 and when v1.01.x gets 100 updates it is at 1.02.x unless a major rewrite updates it higher anyway thats my thoughts

Bryan Hill May 18, 2010 4:52 AM

# re: Which Version of Version?

I maintain a database application and I'm a fan of major.minor.date.time. But in my case, major and minor refer to the database; date and time refer to the code.

major - I've created a new table in the database.
minor - I've changed the layout of the database somehow, or I've added content to my static tables.
date - date the code was compiled into the update (yyMMdd).
time - time the code was compiled into the update (hhmmss).