Software versioning is the process of numbering different releases of a particular software program for both internal use and release designation. It allows programmers to know when changes have been made and track changes enforced in the software.
At the same time, it enables potential customers to be acquainted with new releases and recognize the updated versions.
How to version my Software?
- Why do we need a version anyway? Well, you need some way to uniquely identify the software you have delivered.
- When you add extra information to it, it is also possible to give information about the state of your software.
Best practices for versioning my software
- New projects start at version 0.1.0
- You are starting with a set of features, not bug fixes.
- Increment the minor version for each subsequent release.
- Start versioning at 1.0.0 if:
- Your software is already used in production.
- Other users depend on your software and care when the API changes.
- You are worrying about backwards compatibility.
- The initial development phase is represented by MAJOR version 0
- Make as many breaking changes as you want before v1.0.0
- Once you have released v1.0.0, API adjustments or other breaking changes are not acceptable without a new MAJOR version change.
- If you are adding new features without breaking the existing API or functionality, increment the MINOR number.
- If you are fixing bugs, increment the PATCH number.
The Versioning Problem
It is common for some users of software to ignore how to interpret the sequence of numbers and letters that we usually call version and from there lose all associated information.
It may actually be difficult to understand a software versioning scheme, as there is no one-size-fits-all model. On the contrary, there are multiple versioning schemes with different precepts and characteristics.
Switching away from software version numbers to years seems like one of the wisest decisions.
| Users don’t care about version numbers. | A model year is easy to understand. | Version numbers don’t scale. |
| Major, minor, alpha, beta, build number.. what does it all mean? What users might care about is knowing whether or not the software they’re running is current. | Why should it take two arbitrary numbers and a decimal point to identify what software you’re using? We identify tons of consumer products using a simple model year designator. | Once you get beyond ten versions, what’s the point of meticulously counting every new release? Better to stamp it with a date and move on. |
Who should care about software version numbers?
As a software consumer, the two most important things to understand when reading software version numbers are:
- What (if any) numbering convention is being used?
- What changes have been made to the updated version?
- Enterprise Software Customers: Understand how the provider presents software version numbers.
- Product Development Team: Developers should use software version numbers to help their customers understand how their product has changed and what kind of support they can expect for older versions.
- Software Consumers: Even individual consumers such as smartphone users encounter software version numbers on a regular basis.
Software Version Conventions Done Right
One of the most effective software version conventions involves semantic numbering. Other software version numbering conventions include, date-of-release, alphanumeric codes, sequential numbering, and unary numbering.
Different Types of Versioning
There are numerous variations to think of how you can version your software. Which variation you choose is not so important as long as you keep the following aspects in mind:
- The version identifier must be unique, never re-use the same identifier;
- Choose an identifier which has some logical sequence in it, e.g. alphabetical, numbers.
There are quite a lot of different types of versioning schemes:
- Name Versioning Scheme: Another variant is to use names for your releases.
- Basic Versioning Scheme: Single incrementing digit (e.g. version 1, version 2, …).
- Internal Versioning Scheme: This is the versioning scheme which is visible for your users and which will be used when communicating about releases between you and your users.
Semantic versioning
| Semantic Versioning is a 3-component number in the format of X.Y.Z, where given a version number MAJOR.MINOR.PATCH, increment the | |
| MAJOR | when you make incompatible API changes, |
| MINOR | when you add functionality in a backwards-compatible manner, and |
| PATCH | when you make backwards-compatible bug fixes. |
Version by number: Something common is to handle versions using 3 numbers: X.Y.Z and each one indicates a different thing.
Version by stability: In addition to having versions by numbers, we can add a classification for project stability.
The options we have for this are: Alpha, Beta. Alpha: is an unstable version that is very likely to have many options to improve. Beta: a more stable version than Alpha in which we have the product in its entirety. Patch Version: In the case of patches we can add a digit to indicate the patch: X.Y.Z.Patch
Version by date: We would need to know exactly the date the software was published.
- Public version is intended to be simple and memorable, indicating to customers that it is new & shiny (assuming people generally want “new & shiny”). People don’t understand “10.6.6527.14789” – but they get “2013” or “5”.
- “Windows 7”, “iPhone 5S”, “Office 2013” – are all examples of a public version.
- Private version is what we’re used to in the software world. An internal stamp that (hopefully) uniquely identifies a particular piece of software.
Software versioning is a simple way of how to give a “name” to a unique part of the software. With just a few numbers, you can convey a lot of information about your project’s developmental progress, let users know when there are new important updates, and generally keep things organized. No matter what scheme you decide to use it will be ok as long as it is comprehensible for developers, testers and users.
Also for the QA area is easy when working with continuous integration due to the easy of download the build to test and send it and approve it.
About 4Geeks: 4Geeks is a global product development and growth marketing company, and all-in-between, focused on 10X ROI for startups, small and mid-size companies around the world. 4Geeks serves industries like E-Commerce & Retail, Startups, HealthTech, Marketing, Banking & FinTech and Real Estate. Headquartered in United States, and nearshore development centers in Mexico and Costa Rica. Pura Vida!
Want to start a distributed engineering team? Start right here.
About 4Geeks
Founded in 2012, 4Geeks is a global software engineering and revenue growth consulting firm for Fortune 500, Global 2000 and fast-growing SMBs. Provides top solutions to multiple industries including Retail, Healthcare, Banking & Financial Services, B2B SaaS, Manufacturing and Education. HQ in the USA, and delivery centers across Latin America.