Author: Toraj Khavari
Date: March 31, 2015
Objective: Identify a standard to
reflect a build version number in the A-dec application solutions.
Article Body: Often, I post
solutions in the development, QA and production environments. Right after the
deployment, I get started in something else and forget all about what I posted
for the given project and when. I am sure, there are other Solution Developers
(SDs) relate to this.
Chris,
Jim and I have attempted to take a crack of somehow tying and binding our
solutions’ builds date, version numbers and deployment plans. I took Chris and
Jim’s inputs. I set the following goals for the Assembly Version.
·
Should be strongly names.
·
Must be unique.
·
Should tell the whole story. At least as much as possible.
·
Must represent the enter product.
·
Keep it simple.
After
practicing the following standard for a more than a year in A-dec, I thought to
write it up, during 2011. It makes sense and this is the best I have seen in
practice.
Although,
I use Visual Studio in my example, the concept can be practiced in any
application solution.
There
are 4 fields in the Product Assembly Version Number in VS. I label them from
left to right as follows.
- Major Release
- Minor Release
- Build Date – MMDD – Month follows by day
- Build Date Version – 0 to n.
For
simplicity, let us match the VS File Version with the Assembly Version.
The
definition of Major and Minor releases are as the name implies, refer to a
release with Large or Small changes and enhancements. This two numbers are
decided based on the Developers, Project Managers and Clients (users)
understanding of a given product release. It has to be meaningful and make
sense to anyone sees the number in production.
The
Build Date, MMDD, is the most challenging and confusing indicator. Let us start
with DD. DD is the day of the month, 1 through 31. The MM is “the total months
the project has been created from the January of the year it was first produced”.
Let
us assume, I created a project June of 2010 and it is Feb. 2011 and I need to
edit it, Feb. 16th. The Build Date will be “1416”. 12 months in 2010
plus 2 month in 2011 is 14 for the MM. The 16th of Feb is the DD
part of the Build Date.
The
Build Date Version is the number indicating the number which describes the
build for the given day.
Let us
do a few examples; hopefully it makes it simpler to understand.
Example 1 – I started working on CPS
3.1 during 2nd half of the 2010. I created a test harness Aug. of
2010. I needed to make some changes to it during the time I migrated to Windows
7, Jan. 20 2011. Here is the version number of the test harness project.
1.0.2520.0
Just by
looking at the version number what do you conclude?
The test
harness is a major release “1”. It is a brand new solution. It does not have a
minor release “0”. The project is two
years and a month old which was edited during the 20th of January
“2520”. The deployment build version is
the original build for January 20th “0”.
Note: The
CPS 3.1 harness was created Aug. 2010. The Build
Date’s month is 25 instead of 13, because, the parent solution (CPS3.0) was
initiated during 2009.
Example 2 – Joe is starting
on a project named “Carrier Tracker” during first quarter 2011. Although, there
is an application in production with Version number “1.5.0.0”, the new “Carrier
Tracker”, is a major release. Joe created a project Feb. 14, 2011. Here would
be the version number.
2.0.0214.0
If Joe
edits the same project in June 18, 2011, the number will be as follows.
2.0.0618.0
Example 3 – Matt is working
in a new set of Web services to for Quartz project. The project is created Nov.
2010 by Chris. He is editing it, Feb. 18, 2011. His 4th build is
deployed to QA environment. The version number as follows.
1.1.1418.03
The
practical use of Versioning Assemblies applied to any solution and using any
Integrated Development Environment (IDE). In VS the version information are
saved in the project’s AssemblyInfo.cs file.
The
following simple steps describe the creation and edit of Assembly Versions in
Microsoft VS.
1-
Select the project in the Visual Studio Right
Click > Prosperities (Alt Enter) > Select Application Tab. Select
Assembly Information. Type the Assembly version, File version and enter a GUID.
Select OK.
2-
You are done.
Test the version number.
Open File Explorer > Navigate to the
directory where the assembly is housed > Select the assembly > Right
mouse click > Prosperities > Select Details Tab.
I encourage you to version control and Version
your assemblies. It will enhance most of the System Development Life Cycle
(SDLC) ‘…ability’, e.g., Maintainability, Tractability, Reusability,
Debug-ability, etc, to name a few.
Cheers, Toraj
V.10.5131.01
No comments:
Post a Comment