68

What could every digit mean in software version? (for example, 1.7.1.0) How do you numerate your versions?

starball
  • 20,030
  • 7
  • 43
  • 238
Kirzilla
  • 16,368
  • 26
  • 84
  • 129

6 Answers6

99

It differs from vendor to vendor really. Most commonly, they are (in order):

  • Major release number
  • Minor release number
  • Maintenance release number (bugfixes only)
  • If used at all: build number (or source control revision number)

1.7.1.0 would this be the first maintenance release to the 1.7 version of the product.

Even defining what the difference between a major and minor release is, is difficult. Major releases normally include significant new features. Or the vendor just wants people to pay for the product again. Minor releases may include fixes and new features, but usually nothing ground breaking.

Some companies use the minor release bit to differentiate between alpha / beta releases and final releases. Odd numbers being pre-releases and even numbers being finals. 1.7 would be a beta of an upcoming 1.8 release. This habit is becoming less and less common though.

Build numbers increment with every release, no matter how minor the changes might be. It is automatically incremented by the build process, every time it runs. Many builds are never see publicly released, but they can help in managing the life cycle of the software, by making it easy for QA to uniquely identify a version of the software.

Thorarin
  • 47,289
  • 11
  • 75
  • 111
  • 4
    Mircrosoft appear to do it as, Major part, Minor part, Build part ,Revision part as described by this [page](https://msdn.microsoft.com/en-gb/library/ms973869.aspx?f=255&MSPPError=-2147217396). – Lsakurifaisu Dec 04 '17 at 11:27
  • Major releases are also sometimes used to introduce breaking (non-backward compatible) changes. – Paul J. Lucas Nov 04 '21 at 16:39
36

Normally these are <Major.Minor.Revision.Build>.

Where:

  • Major is a major update to the software
  • Minor is a small update to the software
  • Revision is any change made (bug fixes, small updates)
  • Build number (normally an auto increment if used)

In your example (1.7.1.0):

  • Major version 1
  • Had 7 minor updates
  • First revision/bugfix
  • No build number
Oded
  • 489,969
  • 99
  • 883
  • 1,009
6

Each project chooses its own convention. As others have pointed out, one common convention is "Major.Minor.Revision.Build"

A couple of my favorites are:

Ubuntu versions are "Year.Month". For example, 10.04 was released in April 2010.

TeX versions are theoretically only bux-fixes forevermore, so their versions are asymptotically approaching pi (e.g. 3.1415926)

Terry Lewis
  • 397
  • 2
  • 8
mathmike
  • 1,014
  • 5
  • 10
  • 1
    It's worth noting that more and more projects are switching to release month or date lately because the trend is for frequent releases and the version numbers are getting huge. – Jan Hudec Oct 22 '12 at 08:19
3

Another method widely used is having an incremental build number. Without any correlation to so called "version".

"Version" is more interesting for consumers wanting to know this is a new product, hence you just give every release a name.

But for internal uses and easy reference of product and his tested\source controlled version, a simple incrementing build number might be more convenient.

Amirshk
  • 8,170
  • 2
  • 35
  • 64
2

It depends. Here is information on Microsoft Version Numbers http://en.wikipedia.org/wiki/Microsoft_Version_Number

We have used the last digit as build numbers for our applications.

Sharjeel Aziz
  • 8,495
  • 5
  • 38
  • 37
0

There is a Semantic Versioning specification - semver.org. It declares a version number MAJOR.MINOR.PATCH.

Yura Loginov
  • 710
  • 7
  • 7