Software versioning

Overview

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 1.0.0.0 or 2.1.3.132.

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.

Links

The following Wikipedia links have helped me to define a software versioning system.

Major.minor.build.revision

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:

  • 1.0.0.0
  • 1.0.0.100
  • 2.10.0.0
  • 10.0.0.0
  • 1.1.1.1
  • 10.10.3.10
  • 1.0.0.10030

Invalid versions:

  • 1.0.0.00
  • 1.0.0.01
  • 1.0.01.0
  • 1
  • 1.0
  • 1.0.0
  • 0.1.1.1

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.

Version major

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.

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.

Version minor

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.

Version build

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 1.0.0.0 GUID Maker 1.0.0.0 Pre-alpha
1 Alpha 1.0.1.0 GUID Maker 1.0.1.0 Alpha
2 Beta 1.0.2.0 GUID Maker 1.0.2.0 Beta
3 RC (Release Candidate) 1.0.3.0 GUID Maker 1.0.3.0 RC
4 RTM (Release to Marketing) 1.0.4.0 GUID Maker 1.0.4.0
5 GA (General Availability) 1.0.5.0 GUID Maker 1.0.5.0
6 Gold 1.0.6.0 GUID Maker 1.0.6.0

Version revision

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.