Is there any reason to use one versioning style over the other for .NET assemblies????
I'd like to know if there are any advantages/disadvantages in using either style besides taste.
views:
2120answers:
7
+5
A:
The advantage of time is that you get both an increasing version number and encode the timestamp.
The advantage of using more traditional numbers is that it's easier for people to understand. We all know roughly what "v2.1" means, for example.
In general I suggest using time because the added information is useful. The advantage of the other numbers is for marketing only, and for that you can do it anyway.
For example, why not have both, a la "v2.1.20090214." Now you have marketing in the major.minor section and utility in the "build" section.
Jason Cohen
2009-02-22 21:48:17
If you use a date as the version number, for mercies sake use YYYYMMDD format. It is the only one that just about anybody can read unambiguously, and has the advantage of lexically sorting in the correct order.
Evan
2009-02-23 01:21:52
(For the parochial among us, some countries write their dates in MM-DD-YYYY format, and most of the rest of the sane word writes them in DD-MM-YYYY or YYYY-MM-DD format.)
Evan
2009-02-23 01:24:34
Note that on Win32 (and thus .NET), the version numbers have a 16-bit limit per component, so 20090214 as one component is not possible.
Lasse V. Karlsen
2009-02-23 07:43:04
+2
A:
I just leave the AssemblyVersion at "1.0.*" and remove any AssemblyFileVersion.
I can then increment the Major and Minor version numbers as seems appropriate and let the default DateTime base build and revision be automatically set.
Unless you have alternative build tools controling the build and revision number according to some other scheme I can see no real advantage to setting them manually.
AnthonyWJones
2009-02-22 21:53:23
+1
A:
I use some build scripts that update my revision based on the SVN revision. That makes it trivial to track a dll back to the source code that created it.
Time is trickier; you have to start looking in the history pane - where-as most source control tools have a "get revision " facility.
Marc Gravell
2009-02-22 22:34:53
A:
Why choose? You can use a format such as Major.Minor.YYMMDD.Revision and get the best of both worlds.
Edit As pointed out in the comments sometimes the range of each field is restricted. In that case you can use Major.Minor.YMMDD.Revision.
Hopefully you would change minor version at least every 10 years!
Garry Shutler
2009-02-22 22:40:52
please correct me if a i'm wrong, but according to MSDN at "http://msdn.microsoft.com/en-us/library/system.reflection.assemblyversionattribute.aspx" each component must be a number between 0 and 65535. YYMMDD would be too large. "Major.Minor.YYYY.MMDD" would fit but is ackward :-(
Felipe Angriman
2009-02-22 22:52:33
A:
One disadvantage of date-based version numbering is the negative perception of old software.
Although, I use it anyway because it fits my projects very well.
Doug L.
2009-02-22 22:53:55
Not always a disadvantage. That negative perception can be used to sell your new version.
Strilanc
2009-04-14 18:12:58
+2
A:
Using time/date has one more (apart from those already mentioned in other answers here) disadvantage:
if you're dev team is spread over different time zones, you'll never be sure which one of two versions build one hour apart is the newer one. Unless you also version the timezone or force the date/time to be in e.g. GMT.
Stefan
2009-02-23 07:15:00
+2
A:
The advantage of using major.minor.revision scheme is semantics. There's a method to updating each of these numbers:
Major number change means that the new version is incompatible with the old one and any dependent of the prior version will require code changes to upgrade to the new package.
Minor number change means that the new version is backward compatible with the previous version but has significant enhancements over the previous version.
Revision number is updated whenever a bugfix is applied to the build such that it doesn't bring a compatibility change or introduce newer features.
While specifying dependencies, you can thus say that you depend on foo-1.0.0 - foo-1.99.999, and rest assured that you won't end up with a package upgrade that breaks your application.
If you started with a higher minor version of a dependency, say, foo-1.4.22, you should specify the dependency as foo-1.4.22 - foo-1.99.999, so that you don't end up installing a version older than 1.4.x, which might have some functionality/enhancement missing from it.
codie
2009-09-01 04:52:13