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,547
  • 40
  • 183
  • 216
James Mertz
  • 509
  • 1
  • 7
  • 12
  • "Is there an industry standard". No. Who writes "industry standards"? ANSI? ISO? ECMA? Please don't write a meaningless phrase like "industry standard". Please name a specific standards-writing organization. – S.Lott Feb 14 '11 at 02:04
  • 12
    @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. – James Mertz Feb 14 '11 at 02:17
  • 9
    @S.Lott, cut back on the caffeine sir, it's making you irritable. – ocodo Feb 14 '11 at 02:45
  • @KronoS: If you don't know what a word means (i.e., "industry standard") you can try to look it up. You can also consider that, perhaps, it might be meaningless. The point is this: A question with a meaningless phrase like "industry standard" is quite difficult to answer. If we guess one meaning, you can reject the answers claiming there's some other standard different from the one we're guessing you meant. – S.Lott Feb 14 '11 at 11:03
  • @S.Lott in order to avoid a [flame war](http://www.collegehumor.com/video:1907543) I'll just say this. I'm looking for an understanding of how versions are updated. I was just curious if there's a general rule of thumb (which I titled "industry standard") or if its just up to the programmers. – James Mertz Feb 14 '11 at 15:09
  • @Kronos: "flame war"? I'm providing some advice on how to ask good, answerable, high-value questions. A small change to your question can improve it considerably. – S.Lott Feb 14 '11 at 15:16
  • 2
    @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. – James Mertz Feb 14 '11 at 15:23
  • @KronoS: "I welcome criticism ... I'm leaving it alone." Got it. It's welcome, but won't be acted on. – S.Lott Feb 14 '11 at 15:26
  • 1
    @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. – Adam Lear Feb 14 '11 at 15:47
  • @Anna Lear: The other possible edit might be to remove the meaningless "Industry Standard" and replace something more relevant to the OP's intent, context or situation. – S.Lott Feb 14 '11 at 15:50
  • 3
    @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. – Tamara Wijsman Feb 14 '11 at 15:50
  • 1
    @S.Lott Fair enough. My overall point still stands, though. – Adam Lear Feb 14 '11 at 15:52
  • @S.Lott: You can't answer about a standard without referring to the standard and thus a standards company. It looks like starting a flame war as you aren't giving any advice on how to ask good, answerable and high-value questions; you haven't mentioned early that it was the intention of your comments. We understand now that it was with good intent but please keep that in mind next time... :-) – Tamara Wijsman Feb 14 '11 at 15:52
  • @TomWij: "Perhaps you should have mentioned that you deem the question to broad". Perhaps. Asking for details is one way to discover the intent behind the question. I guess I was wrong in thinking that asking for more information is better than a blanket "I don't like this question" sort of statement. – S.Lott Feb 14 '11 at 15:53
  • 1
    @S.Lott: Asking for more information is fine though, adding the intention of your comment prevents misinterpretation like Slomojo and KronoS (his second comment) had: "Can you specify which industry standard you are looking for? It's hard for us to give a general answer for all industry standards." – Tamara Wijsman Feb 14 '11 at 15:57
  • @Anna Lear: "do feel free to edit". Sadly, I don't understand the question, so I can't effectively edit it. I don't know what "Industry Standard" could possibly mean. I assume there's some meaning behind the question. Other people seem to understand it. I can't figure what meaning they're ascribing to "industry standard". But clearly, many people like the phrase and somehow find meaning in it. – S.Lott Feb 14 '11 at 15:59

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,163
  • 6
  • 55
  • 81
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
  • 3
  • 32
  • 54
  • What is their scheme? Why do you prefer them? – James Mertz Feb 14 '11 at 01:48
  • 3
    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 01:54
  • 2
    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 03: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 03:27
  • 2
    @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. – Martin York Feb 14 '11 at 05:34
  • We use the same version scheme. Though the Build-Number is an encoded date. Thus when testing you can quickly tell which date you are testing against and thus tell when a bug was fixed. – Martin York Feb 14 '11 at 05:37
  • @Martin York, this does not apply to where I work, because there is a lot of back-porting and forward-porting of bugs and features. Python does this as well. This might be easier for a web page, but deployed software quickly becomes messy due to all customizations that clients might want. – Job Feb 14 '11 at 15:00
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
  • 2
  • 4
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
  • 45,784
  • 7
  • 87
  • 160