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.

Some version numbers increase very quickly (like firefox and google chrome) and others don't (like cloudapp and the ubuntu kernel). I'm kinda thinking that the developer chooses how fast the number increments; it'd be silly to add a full +1 to the number if you fixed only minor stuff though....

share

migration rejected from stackoverflow.com 21 hours ago

This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

put on hold as primarily opinion-based by gnat, MichaelT, Ampt, GlenH7, Kilian Foth 21 hours ago

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

1  
Is this for an application or a library? For libraries, there's a (GNU?) convention with three numbers that is very ingenious. –  Kerrek SB Sep 17 '11 at 23:31
12  
you can increment from 3.11 to 95 if you like.. whatever suits you –  Karoly Horvath Sep 17 '11 at 23:33
    
@KerrekSB: add a link for GNU convention? –  IAbstract Sep 18 '11 at 12:24
    
@IAbstract: Here it is: "current", "revision", "age". The idea is that the age field that tells you the range of backwards compatibility. Quite clever! –  Kerrek SB Sep 18 '11 at 13:52
1  
From a customer point of view keep it simple. This is why you see iOS4, iOS5, Firefox4, Windows 7 etc and not iOS 5.2.3.667 etc. You should of course have proper build numbers for your project but when marketing it to customers just keep it simple. –  AndrewC Oct 11 '11 at 19:04

3 Answers 3

up vote 17 down vote accepted

Wikipedia has a discussion of various version number schemes. It really doesn't matter what scheme you use, and your customers probably don't care. The key is that you can identify the version that is being tested or has been released and have quick access to all associated artifacts for that version.

share
    
thanks for the link –  barjak Oct 11 '11 at 19:29

One standard I find amazingly useful is the Semantic Versioning Standard at http://semver.org . It's really short, but straightforward and I haven't found an issue yet that it doesn't cover.

share
    
I was just about to post this as well. It is what I use for versioning all the software I write. –  Mumbles Oct 11 '11 at 18:59

After reading a lot of articles/QAs/FAQs/books I become to think that [MAJOR].[MINOR].[REV] is most useful versioning schema to describe compatibility between project version (versioning schema for developer, does not for marketing).

MAJOR changes is backward incompatible and require changing project name, path to files, GUIDs, etc.

MINOR changes is backward compatible. Mark introduction of new features.

REV for security/bug fixes. Backward and forward compatible.

This versioning schema inspired by libtool versioning semantics and by articles:

http://www106.pair.com/rhp/parallel.html

NOTE: I also recommend provide build/date/custom/quality as additional info (build number, build date, customer name, release quality):

Hello app v2.6.34 for National bank, 2011-05-03, beta, build 23545

But this info is not versioning info!!

@Ed. I specially state: versioning schema for developer, does not for marketing. I use this rules for developer versioning so restrict unnecessery MAJOR + 1. Usually managers or sellers can decide increment MAJOR and this can break code:

if (vmajor != 3)
   error("Incompatable version detected!");

Best is separate versioning for marketing and for developers (and maintain both of them).

share
1  
+1, with one minor tweak: a Major doesn't have to be backward-incompatible - it just may be. There are sometimes other reasons pushing for a major number bump. –  Ed Staub Oct 11 '11 at 19:30
    
@Ed. I specially state: versioning schema for developer, does not for marketing. I use this rules for developer versioning so restrict unnecessery MAJOR + 1. Usually managers or sellers can decide increment MAJOR and this can break **if (vmajor != 3) error("Incompatable version detected!"); –  gavenkoa Oct 13 '11 at 18:49

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