Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
@S.Lott As I'm fairly new to the programming scene I wouldn't know specificities. This is the best way of asking that I could come up with. –  KronoS Feb 14 '11 at 2:17
@S.Lott, cut back on the caffeine sir, it's making you irritable. –  Slomojo Feb 14 '11 at 2:45
@S.Lott feel free to edit as you see fit to better the question. I feel that you know what I'm looking for. However, I do feel that the answers provided have been very good. I also feel, judging by the up-votes on my previous comment, that I've done the best that I can and that the question is ok as is. However I welcome criticism, as well as edits. Do as you see fit. For me, I'm leaving it alone. –  KronoS Feb 14 '11 at 15:23
@S.Lott The question seems pretty clear as is to me. I don't think listing a specific standards-writing organization would be a considerable improvement. If you feel otherwise, do feel free to edit. You have the rep for it. –  Anna Lear Feb 14 '11 at 15:47
@S.Lott: "Is there an industry standard" is completely fine. Yes, there are industry standards! It doesn't matter who writes them: KronoS wants to know what versions mean, it is his choice to specify how detailed he goes... Perhaps you should have mentioned that you deem the question to broad? Just hammering on details doesn't make that clear to the user, telling a user to define:word doesn't make that clear to the user, telling it is meaningless after your first comment doesn't make that clear to the user. –  Tom Wijsman Feb 14 '11 at 15:50
show 11 more comments

4 Answers

up vote 15 down vote accepted

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.

share|improve this answer
add comment

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.

share|improve this answer
What is their scheme? Why do you prefer them? –  KronoS Feb 14 '11 at 1:48
Ubuntu 10.10 = October 2010, Ubuntu 10.04 = April 2010, Ubuntu 11.04 = Aprial 2011, Ubuntu 9.10 = October 2009, etc. This is mentioned in that Wikipedia link by Shaun. –  Job Feb 14 '11 at 1:54
The nice thing about using dates as version numbers is that -- unless some wierd time paradox happens -- your version number will always be in the correct order. For most of us, it's easier to remember that today is 2011.02.13 than it is to try to figure out what version of the new release should be. –  jmort253 Feb 14 '11 at 3:07
@jmort245, Exactly! Man-made systems are quite messy. Freaking banks think that there are 360, 362, 365, 366, etc. days in a year. Versioning system is yet another one of those stupid creations. Timestamps do not make us think, although 20050207 takes a bit longer to read and figure out than 502. What software is released more often than once per month? –  Job Feb 14 '11 at 3:27
@job: But using versions allows you to tie features to specific major or minor versions. So If I have version 2 I know that I have feature X while version 1 does not have version X. –  Loki Astari Feb 14 '11 at 5:34
show 2 more comments

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.

share|improve this answer
add comment

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 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.

share|improve this answer
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.