|
| Assembly versioning: build and revision order. |
|
|
|
|
| Messages |
|
Related Types |
This message was discovered on microsoft.public.dotnet.framework.
| 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.
--
---------------------------------------------------
Automate your software builds with Visual Build Pro
http://www.kinook.com
"Alek Davis" <alek_xDOTx_davis_xATx_intel_xDOTx_com> wrote in message
news:%Click here to reveal e-mail address...
[Original message clipped]
|
|
|
| |
|
| |
| |
| 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
"Kyle Alons" <Click here to reveal e-mail addressup> wrote in message
news:Click here to reveal e-mail address...
> Good question. In the .NET era, Microsoft seems to have changed their
mind
[Original message clipped]
|
|
|
| |
|
|
| |
|
|
| |
| Robert French |
Your not nuts, and your thinking is logical, however we have found a great reason for following the .NET versioning (even though we can't currently take advantage of .NET)
We use EPOCH then divide by 60 twice to generate our build numbers (giving the number of hours since midnight Jan 1 1970) this provides a way to determine the exact date/hour the product was built ... since we make it a policy to only build once an hour per product this works well 99.9% of the time and the revision is almost always 0, but there have been exceptions to the rule, where we have to re-use the same build number (somthing was missed that only takes a second to fix)... having the revision after the build provides us a method to handle and track the exception without having to increase the build number by an hour ;-)
Thoughts? Feedback? Flames?
All are Welcome
--------------------------------
From: Robert French
|
|
|
| |
|
| |
|
|
|
|
|
|
|
|
BootFX
Reliable and powerful .NET application framework. |
|
|
|
|
|
|
