The purpose of this document is to outline information about how I version software in a software development life cycle.
I use a four part version number, it's Major.Minor.Build.Revision. An example of this would be 220.127.116.11 or 18.104.22.168.
The creation of software needs stepping stones, or milestones, that can be marked by releases. These releases are versioned in a way that shows what part of the development life cycle the software was in. It's only one part of the version number, and it's called the build.
The following Wikipedia links have helped me to define a software versioning system.
I follow a version of Major.Minor.Build.Revision. Out of all of the positions, Build is the only position that will always mean the same thing for all software releases, provided I don't change the meanings for Build. At this point if you've been reading from the top of the page with no knowledge of this stuff it might seem confusing, just read on and it should start to make more sense once you know exactly what each position is.
Valid versions contain all positions, that's Major.Minor.Build.Revision. All positions except for Major can be zero to whatever, but cannot start with zero unless it is zero. Major needs to be one or greater.
The Major version is directly related to the product name. Some names include the version in it, others do not. In the case of no version reference you need to look it up yourself. From what I've researched it's standard practice to increase the Major version in the release of a new product. What that means is that the old product is not replaced with the software as an upgrade, it's an entirely new product.
The following research of my software release names show what I'm talking about.
This is a perfect example of a name that does not need the version in it, but it still shows what the more recent release is.
The major version is in the name, so you will always know which version is newer.
The name Tic-tac-toe in this product line will always be the same. In this type of naming convention the user would need to look up the version to find out if it's the latest.
This software does not include the version in the name but its name will change in a new product. For example, version 2 could be called Calendar Sweetheart. The user would need to look up whether or not it's the latest product available.
It obviously does not make sense to expect end users to be vigilant of new releases, and they shouldn't. I can easily add a menu item saying Download Newer Product, or include the information within an upgrade check some how. Ultimately, there is no reason a user should fret about having the latest version, a good software developer will provide that to you.
It's funny that Minor is called minor because it gets changed when a major change in the software occurs, or any foundation is changed. I change the minor version to software if there is a big change in the license, other than that I haven't increased the minor version. It could also change if the Operating System was changed or any other underlying tech like that was changed.
Build is the only version whose meaning is always known. For more information about each build, visit the Wikipedia link above.
Here's my Build definition:
|Value||Build||Version||Example Full Name|
|0||Pre-alpha||22.214.171.124||GUID Maker 126.96.36.199 Pre-alpha|
|1||Alpha||188.8.131.52||GUID Maker 184.108.40.206 Alpha|
|2||Beta||220.127.116.11||GUID Maker 18.104.22.168 Beta|
|3||RC (Release Candidate)||22.214.171.124||GUID Maker 126.96.36.199 RC|
|4||RTM (Release to Marketing)||188.8.131.52||GUID Maker 184.108.40.206|
|5||GA (General Availability)||220.127.116.11||GUID Maker 18.104.22.168|
|6||Gold||22.214.171.124||GUID Maker 126.96.36.199|
Every release receives an increase in revision no matter what, and the first release is zero. By the final releases of a product this number will more than likely be high.