Vertioning Number Rules

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
1. New projects start at version 0.1.0

o You are starting with a set of features, not bug fixes.
o Increment the minor version for each subsequent release.
2. Start versioning at 1.0.0 if:
o Your software is already used in production.
o Other users depend on your software and care when the API changes.
o You are worrying about backwards compatibility.
3. The initial development phase is represented by MAJOR version 0
o Make as many breaking changes as you want before v1.0.0
4. Once you have released v1.0.0, API adjustments or other breaking changes are not
acceptable without a new MAJOR version change.
5. If you are adding new features without breaking the existing API or functionality,
increment the MINOR number.
6. 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 A model year is easy to Version numbers don’t
version numbers. understand. scale.
Major, minor, alpha, beta, Why should it take two arbitrary Once you get beyond ten
build number.. what does it numbers and a decimal point to versions, what’s the point of
all mean? What users might identify what software you’re meticulously counting every
care about is knowing using? We identify tons of new release? Better to stamp
whether or not the software consumer products using a simple it with a date and move on.
they’re running is current. model year designator.
Who should care about software version numbers?
As a software consumer, the two most important things to understand when reading software
version numbers are:
1. What (if any) numbering convention is being used?

2. 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
when you make incompatible
MAJOR
API changes,
when you add functionality in
MINOR a backwards-compatible
manner, and
when you make backwards-
PATCH
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.
The software release cycle

Any well-maintained piece of software will receive a regular cycle of updates and upgrades.
(Which are not the same thing – more on that shortly.)
Over time, as its developers work away, a software product will scale and change. It will
integrate into more services, get new features, incorporate a series of design changes and
security updates, and so on. Simply, your software product doesn’t remain static.
So, whether it’s an entirely rewritten codebase or a simple bug fix, each release changes your
product in some way.
And this means that, inevitably, developers create multiple different versions of the product
during its lifecycle. In turn, tracking those releases can become confusing.
Enter software version numbering rules.
A numbers breakdown
Let’s go back to the number we used as an example at the start of this post: Version 17.4.26.
Each number in that sequence refers to a specific release type:
 Major releases (indicated by the first number)

 Minor releases (indicated by the second number)
 Patches (indicated by the third number)
In this instance, Version 17.4.26 means that:
 Your current product has had 17 sweeping upgrades (versions) during its lifecycle
 This current version of the product has since received four updates
 The current version has been patched 26 times
Clear and consistent software version numbering rules, then, make it easy to track where
you’re at with your current release.
But reading the numbers properly also requires a little more understanding behind the various
release types.
A release type breakdown

So: Version 17.4.26. We now know that those numbers respectively refer to major releases,
minor releases, and patches.
Let’s look at what that means in closer detail.
 Major releases
Also known as versions or upgrades. A major release represents a significant product change
– a rollout of game-changing new features, an overhauled interface, a fresh new codebase.
Typically, a major release will supersede previous versions of the software.
 Minor releases
Also known as updates. A minor release edits the current version in a small way – usually to
enhance existing functions. (Or, sometimes, to add lesser new features.) This will happen
regularly and mostly in the background.
 Patches
Also known as bug fixes. A patch often isn’t part of a planned release, as it will generally
come in response to an uncovered problem or a new security threat. They help keep your
product running effectively, even if they don’t offer new functionality.

Vertioning Number Rules

Uploaded by

Copyright:

Available Formats

Vertioning Number Rules

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Vertioning Number Rules

Uploaded by

Copyright:

Available Formats

Software versioning is the process of numbering different releases of a particular software

How to version my Software?

Best practices for versioning my software

1. New projects start at version 0.1.0

The Versioning Problem

It may actually be difficult to understand a software versioning scheme, as there is no one-

Who should care about software version numbers?

1. What (if any) numbering convention is being used?

 Enterprise Software Customers: Understand how the provider presents software

 Product Development Team: Developers should use software version numbers to

 Software Consumers: Even individual consumers such as smartphone users

Software Version Conventions Done Right

Different Types of Versioning

There are quite a lot of different types of versioning schemes:

 Name Versioning Scheme: Another variant is to use names for your releases.

Semantic Versioning is a 3-component number in the format

Version by stability: In addition to having versions by numbers, we can add a classification

 Public version is intended to be simple and memorable, indicating to customers that

The software release cycle

 Major releases (indicated by the first number)

In this instance, Version 17.4.26 means that:

A release type breakdown

You might also like