Tell me more ×
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.
up vote 10 down vote favorite
2

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|improve this 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
10  
you can increment from 3.11 to 95 if you like.. whatever suits you – yi_H 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. – AndyC Oct 11 '11 at 19:04
show 2 more comments

migrated from stackoverflow.com Sep 18 '11 at 12:17

4 Answers

up vote 15 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|improve this answer
thanks for the link – barjak Oct 11 '11 at 19:29
up vote 7 down vote

the whole idea is

2.3.5.1025

  • 2 = Major
  • 3 = Minor (Features)
  • 5 = Fixes (Fixes to Minor)
  • 1025 = Build number
share|improve this answer
1  
You forgot build number. 2.3.5.1025 – the_drow Sep 18 '11 at 12:20
5  
It's one idea among a lot of others – Nikko Sep 18 '11 at 13:03
1  
Surely this is not the only possible versioning scheme, but a very common one. – Doc Brown Sep 18 '11 at 20:05
You haven't defined what the major number means. – barjak Oct 11 '11 at 19:28
This is the system I like. I especially like including the build number (which is just the seriel number of the last source control check-in). That's the best way I've found to identify the exact point in time the product was built. – Jim In Texas Oct 13 '11 at 20:05
up vote 7 down vote

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|improve this answer
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
up vote 3 down vote

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|improve this answer
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

Your Answer

 
discard

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.