What is your preferred style of product version number and why?

Question

Is it Major.Minor.Release - IBM style (eg. 1.2.3)? Is it the Year? (Windows '98) Something else?

Reference: http://en.wikipedia.org/wiki/Versioning

Presently I use major.minor.release.internal-release

Example 01.12.02.19

For the next product, I was thinking of making it simpler Version-Build

Example v1-b22

Before I finalize ('cause I will have to live with my decision for the rest of the product's life) I want to get as many points of views as I can.

Thanks much!

Answer 1

I primarily develop webapps, and for me it's just a little rev #xxx at the bottom of the page (which is a programically retrieved mercurial revision number)

Answer 2

Those used by TeX and METAFONT.

Answer 3

I like two different methods.

First Method - major.minor.date_of_build

So, something like: 3.0.20090120. That way, if I need to know when a specific release was made, I just need to look at the last number.

Second Method - major.minor.repository_value

I like this because I can always find it within my repository.

Hopefully that helps a bit.

Answer 4

[major].[minor].[patch]

For example: 2.0.4

Major is incremented when the product has many new, major features, minor is incremented when a few minor features are added, patch is incremented when no new features are added, but bug fixes or security issues have been patched.

I prefer this because it's simple, efficient, and most people understand these version numbers without explanation, even non-developers.

Answer 5

Is this for internal or external use?

For the former, I like to have major.minor-timestamp. The latter, I tend to use Product Name Major.Minor.

//internal
2.8-1234567890

//external
Wordpress 2.8

Answer 6

I'd go for product version + build. I think people have a tendency to over-think this problem. Design a simple scheme where your users can easily find out the answer to two questions:

1. Do I have the most up-to-date build of this product?
2. Is there a new version I should consider upgrading to?

This assumes that intermediate builds are free upgrades, and major version changes are paid.

Answer 7

We tend to do a major release each year, with minor releases in between. So our splash screen and About box display the program versions as "2009", "2009a", etc.

We also have build numbers within that, which are incremented every time we do an automated daily build for QA. So our full version number might be something like 2009a.78.

As far as Windows version resources go (the x.x.x.x format), our 2009a.78 would be 2009.1.78.* (where '*' is Visual Studio's "autonumber based on the current time within the day" -- something like 18230).

Answer 8

[Major].[Minor].[BuildDate].[DayBuildNo]

Where BuildDate is reverse numeric, i.e. 090813 and day build number can be anything - minutes since midnight is good or even a manual tally

For internal software I tend to drop the major/minor too - just being able to glance at the splash screen and see when the version was made is pretty useful, and keeping it short helps users if they need to report a bug.

Answer 9

I use the following form:

[Year].[Month].[Revision]

[Revision] is a Subversion revision number in my case.

This style helps our customers is to easily distinguish product's versions. The revision number helps our developers is to easily find appropriate sources to fix bugs.

Answer 10

I use something like DevExpress does. My format is [Year-last 2].[Month].[Day].[IncrementalBuildNumber], i.e 9.8.12.2569. The build number starts at 1 and increments over the live of my application.

DevExpress basically does [Year].[Minor-based at 1].[Revision], i.e. 2009.1.5 is their current version which they equate to the 5th revision of Volume 1 of the 2009 release calendar.

Answer 11

Internally, we use a Major.Minor.Patch.Year. What our customers see is Year.Release for the year Patch (if needed), i.e. 2008.4 (fourth release last year) or 2009.2 B if we needed to patch it.

Edit (forgot this part): Our reason for the difference? Internally, we haven't changed systems at all since initial release. Externally, senior management wanted it displayed this way.

Answer 12

I like Knuth way he used with LaTex :π

3
3.1
3.14
3.141

I am sure no body would use it except Knuth, and me probably :)

Answer 13

I prefer any variant of the following:

[major].[minor].[wayToTrackAnInternalBuild]

For example, using a build number:

[major].[minor].[buildnumber]

Using a repository revision:

[major].[minor].[revision]

Or a date:

[major].[minor].[date]

Its conventional to have at least a major and minor number. Prefixing with a "v" seems to be less common these days.