Assembly versioning: build and revision order.

  • Thread starter Thread starter Alek Davis
  • Start date Start date
A

Alek Davis

This question has been bothering me for a while. Why is (according to MSDN
doc) version string is defined as
major.minor[.build[.revision]]? These scheme suggests that there may be an
assembly with the same build number but different revisions, e.g. 1.5.1044.2
and 1.5.1044.3. This does not make much sense (how can you get a new
revision without building the assembly?). Shouldn't the version be defined
as major.minor[.revision[.build]]? The way I think about it is this. Major
and minor versions basically define the version of application. Revision
should indicate whether assembly code has been changed (either because of
added/removed functionality or bug fixes). Finally, build number should be
incremented every time assembly code is recompiled (even if code has not
changed). In this case, if the major.minor[.revision[.build]] scheme were
used, it would be possible to define version in the AssemblyInfo file like
1.5.2.*. So as a developer, I would know that if I make any code changes, I
will have to change the version to 1.5.3.*, but if I simply recompile the
assembly as part of the solution without code changes (maybe because code in
some other project belonging to the same solution was modified), I can keep
the version the same (1.5.2.*) and the build number will be incremented
automatically. With the current scheme (major.minor[.build[.revision]]),
this is not possible (you cannot define the version as 1.5.*.2). Am I nuts
or does it make sense to others? Do I miss something?

Alek
 
Good question. In the .NET era, Microsoft seems to have changed their mind
on the version field naming. These search hits provide some insight into
this issue:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&q=major.minor.revision.build&sa=N&tab=wg

If you follow the first thread, it comes down to this: The ECMA standard
(which Microsoft submitted parts of .NET to) says
major.minor.revision.build. MSDN (generally) says
major.minor.build.revision.

I would tend to agree with your argument.
 
Thanks Kyle,

I did not know about ECMA standard. Just wondering what the rationale behind
MSFT decision was. Any way I look at it, it is not logical. Assuming that
MSFT team making this decision did not do it after a Spring break party,
there might have been some reason for the change. Someone might have said:
"Well, we - and everybody else - were doing it this way, but from this point
on we will do it differently because..." I guess, we will never know.

Alek

Kyle Alons said:
Good question. In the .NET era, Microsoft seems to have changed their mind
on the version field naming. These search hits provide some insight into
this issue:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&q=major.minor.revision.build&sa=N&tab=wg

If you follow the first thread, it comes down to this: The ECMA standard
(which Microsoft submitted parts of .NET to) says
major.minor.revision.build. MSDN (generally) says
major.minor.build.revision.

I would tend to agree with your argument.

--
---------------------------------------------------
Automate your software builds with Visual Build Pro
http://www.kinook.com

Alek Davis said:
This question has been bothering me for a while. Why is (according to MSDN
doc) version string is defined as
major.minor[.build[.revision]]? These scheme suggests that there may be an
assembly with the same build number but different revisions, e.g. 1.5.1044.2
and 1.5.1044.3. This does not make much sense (how can you get a new
revision without building the assembly?). Shouldn't the version be defined
as major.minor[.revision[.build]]? The way I think about it is this. Major
and minor versions basically define the version of application. Revision
should indicate whether assembly code has been changed (either because of
added/removed functionality or bug fixes). Finally, build number should be
incremented every time assembly code is recompiled (even if code has not
changed). In this case, if the major.minor[.revision[.build]] scheme were
used, it would be possible to define version in the AssemblyInfo file like
1.5.2.*. So as a developer, I would know that if I make any code
Click to expand...
changes,
I
will have to change the version to 1.5.3.*, but if I simply recompile the
assembly as part of the solution without code changes (maybe because
Click to expand...
code
in
some other project belonging to the same solution was modified), I can keep
the version the same (1.5.2.*) and the build number will be incremented
automatically. With the current scheme (major.minor[.build[.revision]]),
this is not possible (you cannot define the version as 1.5.*.2). Am I nuts
or does it make sense to others? Do I miss something?

Alek
Click to expand...
Click to expand...
 
Back
Top