.NET Questions (CLOSED)

Questions and Answers on any aspect of .NET. Now closed.

This discussion group is now closed.

Have a question about .NET development? Try stackoverflow.com, a worldwide community of great developers asking and answering questions 24 hours a day.

The archives of .NET Questions contain years of Q&A. Even older .NET Questions are still online, too.

AssemblyVersion format

Guys,

Tell me what you think of this idea:

Instead of applying version numbers in the standard "Build.Maj.Min.Rev" format, I'm thinking of using "Year.Month.Day.Rev".

So instead of "1.0.2.12432" I might have "2007.2.14.0".  It would be a lot easier to identify when an assembly was actually built.  I'm about to put together a pre-build task to inject the correct values into the AssemblyInfo file, but wanted to validate my idea first.

Comments?
UK Techie Guy
Wednesday, January 10, 2007
 
 
If you're going to be signing your assemblies, you're going to have lots of problems with getting references set up properly if your version changes with every build.
Chris Tavares Send private email
Wednesday, January 10, 2007
 
 
The first and second sections of a version number are pretty universally regarded as major.minor.  Futz with the third and fourth sections if you want to encode custom information.
Jake
Wednesday, January 10, 2007
 
 
If you use major.minor.* in the AssemblyVersion attribute, then .NET will automatically set the 3rd and 4th parts of the version based on the date (3rd) and time (4th) that the assembly was built.  Check the docs for details.
John Rusk
Wednesday, January 10, 2007
 
 
Thanks for the replies.

What I really want to do is use a version that reflects the product name, which I want to call "<My Product> 2007".  So I was thinking that the version should also reflect that (2007.2.14.0).

If I release a new version in 2008, it would be called "MyProduct 2008" (with the appropriate version).

There would be infrequent releasees of the product, so I'm not too concerned about correcting assembly references, and I'm using VS2005, which doesn't support the asterisks anymore.

In the enterprise, keeping track of version numbers is a major headache for IT support teams.  My thought is that people would have a better chance of remembering a date/month than some random version number. They could associate a new release with a time frame ("Hmmm, I was on holiday when the software was upgraded, so maybe I should look for version 2007.6.x.x...")

No one has actually said "This is a REALLY BAD IDEA yet"...

Cheers.
UK Techie Guy
Friday, January 12, 2007
 
 
The major version number is a technical mechanism to keep track of when a major new version is issued. A year number in the product name is a marketing ploy to encourage users to associate the product release with a particular year. Binding the two together might be a bad idea, because they don’t necessarily change at the same time.

For example, might you release <My Product> 2008 at the end of 2007, for marketing purposes, instead of waiting until 2008? Alternatively, might you continue to release updates to <My Product> 2008 beyond 2008? Both scenarios would break the strategy that you are trying to implement.
Mike Send private email
Friday, January 12, 2007
 
 
Cheers Mike. Well spotted - looks like I'll have to go with the standard approach.

Thanks everyone.
UK Techie Guy
Friday, January 12, 2007
 
 
We're doing this with our assemblies to stamp it with the date it was built:

<major>.<minor>.<julian-date>.<build-per-day>

eg.
2.0.7015.5

The <julian-date> and <build-per-day> would be read as:

2007/01/15, fifth build of that day.
James
Monday, January 15, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz