Praxent

A Complete Guide to Understanding Software Version Numbers

A Complete Guide to Understanding Software Version Numbers


What Is A Software Version Number?

Software version numbers indicate changes in a software product. As developers update and improve products, there are often several versions of the product available for end users. At the very least, developers will always create two versions of their software.

  • Stable Version: The version all end users have
  • Working Version: The version the development team is working on daily to enhance the product

Not only do version numbers indicate that a product has been altered or improved on some level, they can also be used to communicate other important information.

Order of Release

In general, software version numbering indicates an order of release in some way. If you line up all versions of a product from the original to the most recently updated version, you will be able to tell the order in which they were released by looking at the version numbers.

Degree of Change

Many software versioning conventions indicate the degree to which a version has been changed. These numbers help users understand whether the newest version has been changed a small amount or quite a lot since the previous version.

Date of Release

In some cases, you can decipher the date on which an updated software was released by looking at its version numbers. This is helpful in understanding which software versions are the oldest and which are the newest.

>> Wondering whether to buy or build? Build vs. Buy Software: Pros, Cons & Six Questions to Consider before Taking the Plunge

Who Should Care About Software Versioning?

Whether you’re an IT professional managing your company’s enterprise software, a team leader running an automated factory floor, a developer creating products used by these companies, or simply a smartphone user, software version numbers are written for you. It’s essential for both managers and end-users to understand the software version numbering rules being used in their products. It’s also essential for developers to implement a well thought out software versioning strategy from the beginning.

Reading Software Version Numbers

The two most important things to understand when reading version numbers are:

  1. What (if any) numbering convention is being used?
  2. What changes have been made to the updated version?

For consumers less acquainted with a product’s version numbers, it’s crucial to read the release notes of any software product before blindly updating software to the latest version.

Similarly, developers and teams charged with releasing upgraded versions of their software products should mindfully take the following into consideration when it comes to software versioning strategy:

  1. What numbering convention will you use and why?
  2. Does your numbering convention help your customers make educated decisions about whether or not to upgrade?

Ideally, when thinking about how to version software, teams should choose a convention that facilitates best practice when it comes to improving software incrementally as well as communicates changes to customers.

Enterprise Software Customers

If you’re an enterprise software customer, you should keep the following guidelines about software version numbers in mind when working with IT partners or software providers.

  1. Understand how the provider presents version numbers
  2. Ensure the provider is adhering to standard software version numbering rules. If they aren’t, it could be a sign of sloppy or thoughtless work in other areas
  3. Understand how frequently updates will be released
  4. Know what type of testing will be conducted at each level of release. A bug fix, for instance, will understandably undergo far less rigorous testing than a full major version update. For major version updates, however, you’ll want to know whether or not the provider is sifting out potential risks for you before releasing the update. If they aren’t, then that could be a good reason for you to either decline an upgrade or implement user testing on your own before adopting the new version company-wide.
  5. Understand all changes that have been made with each new version of the product
  6. Find out if the software provider has a backup plan in case the new version fails in some way
  7. Make sure you have a safety net in case the new version causes significant issues. You’ll want to safeguard your company’s ability to revert back to the old version in such cases. Make sure you know how to revert back before saying “yes” to the upgrade.

>> Off-the-shelf software may be just what you need…or it may not. Here’s what to do when your inefficient software is costing you more than it’s worth.

Product Development Teams

Developers and businesses should use software version numbering to help their customers understand how their product has changed and what kind of support they can expect for older versions.

When thoughtlessly managed, software version numbering rules can be confusing for both users and developers. It’s important to ensure your team is adhering to release versioning best practices upfront. Under the semantic numbering convention (more on this below), the numbers work as follows:

  • First Number: Tracks major changes
  • Second Number: Tracks minor changes
  • Third Number: Tracks patches or mere bug fixes
  • Fourth Number: Tracks changes less significant than a patch

For example, we are aware of a company that recently released version number 2.1.5.43 of their software product. They are using semantic numbering to keep track of their new releases. You can tell from the version number 2.1.5.43 that this company has not put much thought into which version number to change as they update their product. The development team appears to have a habit of just updating the least significant version number every time they make a change. After 43 updates, there have almost certainly been alterations to the product. Nonetheless, they are still incrementing the fourth number 43 versions later. Not only is this confusing for users who have almost no way of telling what each update has accomplished, it’s also bad for the company.

Good luck trying to get users to upgrade! This product has 43 different versions, each with an untold number of differences. Users will almost certainly be reluctant to risk changing their current version for something so ambiguous.

Software Consumers

Even individual consumers encounter software version numbers on a regular basis. Thus, it’s important for companies to think through version numbering to effectively communicate information to their consumers. For users, it’s essential to pay attention to these numbers and understand what they mean for the software’s design and function.

Commonly, software version numbers will help you differentiate between major and minor changes using a semantic numbering convention. Take a look at what version you’re on and what version an update is. If the number representing major changes has been incremented, then understand that a lot of things will change once you go through with the update. If the number representing bug fixes has been incremented, then you risk very little change in the way you use the product.

It’s important to read the release notes to understand what the changes will be before implementing an upgrade.

Software Version Conventions Done Right

A software version convention is defined as a numbering pattern that developers and their customers use to track updates and releases to the software product. When software version numbers adhere to best practices and a version convention of some sort, they can help users and other developers understand the risk associated with upgrading a product.

There are several common conventions for software version numbering, including:

  • Semantic Numbering
  • Date-of-Release
  • Alphanumeric Codes
  • Sequential Numbering
  • Unary Numbering

One of the most effective software versioning conventions involves semantic numbering.

Semantic Numbering

With semantic numbering, developers communicate the degree of change associated with each software update by categorizing versions into major, minor, and bug or patch updates. The patch number is incremented for changes that are not meant to alter the product’s existing functionality. Companies usually increment this software version number after fixing a bug that’s been introduced to the product.

Minor Version Number Updates

The minor version number is incremented when developers add new features to the product that are still compatible with former versions in the same major category. For example, a 2.1.4 version will still be compatible with 2.2.0. If a software provider has released minor version updates, it’s likely they will still support users who do not upgrade because the updates are backward-compatible. With minor version updates, users will definitely see changes to the software’s functionality and features. But the change is less risky for users because it still runs along the same vein of compatibility as other minor versions in the same major category.

Major Version Number Updates

When developers make significant changes to a software product’s API, they will increment the major version number. This means that the changes are extreme, to the point that they render the software incompatible with older versions. At this point, the product has evolved drastically. It is no longer operating on the same vein as former versions. For example, while a 2.1.4 version would likely be compatible with a 2.2.1, it may not be compatible with a 3.0.0 or higher.

Occasionally, you’ll find software versioning conventions that involve dates or letters of the alphabet. These conventions generally track the same thing — minor versus major changes — using a different nomenclature.

Learn More

The only wrong software version number is the one that’s not following a convention. If you find yourself using software that doesn’t follow a versioning convention, you’ll want to be extra careful about making updates. This could also be a sign that it’s time to start looking for a different software or IT provider.

>>When it comes to enterprise software products, Praxent understands the importance of reducing risk and over-communicating. Contact one of our software maintenance experts today for a free consultation.

 



10 Signs of a Qualified Design & Development Partner: A Handy Checklist for Product Owners

Building a new digital product or updating an older one is a huge endeavor – only teams of seasoned experts can properly manage the job and be trusted to help you shoulder ownership of the outcome.

> Download the e-book for a helpful list of partner qualifications, from technical to cultural, and more.