19

A lot of software updates follow the scheme of v0.1 to v0.2 to v2.6.5.6. What do these "updates" to software really mean? Is there an industry standard always followed or do programmers pretty much keep raising the update # or adding more decimals?

yannis
  • 39,647
James Mertz
  • 509
  • 1
  • 7
  • 12

4 Answers4

16

Like Shaun said, there isn't really a standard. Some companies have better versioning practices than others (I've dealt with vendors who skip major version numbers, and others that are stuck on the same x.y several releases later).

Having said that, the inventor of Gravatars and cofounder of GitHub (Tom Preston-Werner) authored a document for 'Semantic Versioning' which is more than worth a read.

Here's the except of the intro:

As a solution to this problem, I propose a simple set of rules and requirements that dictate how version numbers are assigned and incremented. For this system to work, you first need to declare a public API. This may consist of documentation or be enforced by the code itself. Regardless, it is important that this API be clear and precise. Once you identify your public API, you communicate changes to it with specific increments to your version number. Consider a version format of X.Y.Z (Major.Minor.Patch). Bug fixes not affecting the API increment the patch version, backwards compatible API additions/changes increment the minor version, and backwards incompatible API changes increment the major version.

I call this system "Semantic Versioning." Under this scheme, version numbers and the way they change convey meaning about the underlying code and what has been modified from one version to the next.

James Mertz
  • 509
  • 1
  • 7
  • 12
Dan McGrath
  • 11,181
  • 6
  • 57
  • 82
7

With 4 digits it is usually MajorV.MinorV.PatchNum.BuildNum, at least where I work.

I personally prefer the Ubuntu's versioning scheme - makes life so much easier.

Job
  • 6,459
6

The short version is that there is no standard and companies do whatever they want. Essentially, the more numbers you have, the smaller the amount of changes each number represents. Commonly, you'll see at least version x.y, where x a change in x signifies major releases (major enhancement/feature rollouts) and y signifies minor releases (significant tweaks or defect fixes). More decimals after those two can mean different things internally to a company although often revolve around minor content builds or patches that represent quicker and smaller fixes.

Wikipedia has an article that covers this in greater detail.

Shaun
  • 371
3

The purpose of version numbers is to provide a reference for problem reports. The only requirement is that every release has a unique version number. Some numbers are driven by marketing--bigger whole numbers are easier to sell, and power numbers like 10 (roman numeral X) are really catchy. Some people use some variation of semantic versioning:

MAJOR.MINOR.MICRO.BUILD

  • Major increments: incompatible changes or complete redesign of the UI
  • Minor increments: new features added, compatible with prior versions in the same major version number
  • Micro increments: bug fix release
  • Build number: generated by the compiler or pulled from version control

Many groups drop the BUILD number in their releases. It's usually only useful between testing and development groups.

Some groups add additional semantics, such as odd numbered MINOR increments are for experimental builds and even numbered MINOR increments are for production releases (Linux kernel uses this approach).

Bottom line is that there is no standard, other than newer versions use higher version numbers, and that each version number is unique.

Berin Loritsch
  • 46,426