Software Build & Release Versioning Strategy

The blog represents the software build and release versioning strategy which can be used to tag web or mobile releases with different version numbering schemes as illustrated later. The strategy can as well be used for software versioning.

Build/Release Version Numbering Scheme – <major>.<minor>.<patch>.<buildnumber>

A release version can be of type <major>.<minor>.<patch>.<buildnumber>. Following is what each of these keywords such as major, minor, patch and buildnumber represents:

• major: Indicates a significant change in the application which may essentially mean one of the following:
  • The app is re-written
  • The app has changed significantly so much so that backward compatibility with older versions gets broken.
  • Large set of new features
  • At times, new UI can also be released as major release.
• minor: Indicates the release of one or more newer features or major enhancements representing a set of bug fixes on previous major release. Minor releases do not break the backward compatibility of the product.
• patch: Indicates one or more bug fixes related with one or more existing features which need to be released in between minor releases. Patch release never releases a new functionality.
• buildnumber: Indicates the build number. Build number is incremented with each new build.

Based on above, a major release can be 1.0.0.0. A hotfix release would go as 1.0.1.12 which means twelth build of hotfix release 1.0.1. Using buildnumber is optional. One can simply tag releases using format such as major.minor.patch. However, it provides greater visibility on the stability of release when tagged using format such as ….

Build/Release Version Numbering Scheme – <major>.<minor>.<patch>.<type>

An alternate versioning scheme used is <major>.<minor>.<patch>.<type>. Keyword type represents following:

• type: This is an optional keyword. It can be used to represent the stability of the release. Some of the example of “type” keyword is alpha, beta or for that matter, SNAPSHOT, RC etc.

Strategy for Managing Builds & Releases with Version Numbering Scheme

The following strategy can be used to manage builds and releases with one of the version numbering schemes described in preceding sections:

• Create new build jobs in your CI tools with versioning numbering scheme such as <major>.<minor>.<patch>.<$BUILDNUMBER>. Here, BUILDNUMBER is a variable which CI tool will increment with every new build. CI tools such as Jenkins does support this numbering scheme.
• The build jobs mentioned in above point will be working with different QA/release branches.
• During release, the release branches can appropriately be merged into Master and each other.

Useful Links on Release Versioning Strategy

• Maven Versioning Strategy
• Software Versioning
• What do the numbers in a version typically represent (i.e. v1.9.0.1)?
• What every digit means in software version (1.7.1.0, for example)?
• Version Numbers and Build Numbers

• Author
• Recent Posts

Follow me

Ajitesh Kumar

I have been recently working in the area of Data analytics including Data Science and Machine Learning / Deep Learning. I am also passionate about different technologies including programming languages such as Java/JEE, Javascript, Python, R, Julia, etc, and technologies such as Blockchain, mobile computing, cloud-native technologies, application security, cloud computing platforms, big data, etc. For latest updates and blogs, follow us on Twitter. I would love to connect with you on Linkedin.
Check out my latest book titled as First Principles Thinking: Building winning products using first principles thinking. Check out my other blog, Revive-n-Thrive.com

Follow me

Latest posts by Ajitesh Kumar (see all)

• MSE vs RMSE vs MAE vs MAPE vs R-Squared: When to Use? - April 22, 2024
• Gradient Descent in Machine Learning: Python Examples - April 22, 2024
• Loss Function vs Cost Function vs Objective Function: Examples - April 19, 2024