Assembly versioning: build and revision order.

[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

 

[Kyle Alons]

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.

 

[Alek Davis]

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

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

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