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

[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 2

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 3

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 4

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.

Answer 5

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 6

Those used by TeX and METAFONT.

Answer 7

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 8

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 9

[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 10

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 11

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 12

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 13

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 14

I've personally used the X.Y.Z model of semantic versioning until now. For a long time, this has fit the use and the overall user base's needs.

What I've realized from switching from trying to use different models of organising version information is that it will be heavily dependent on what you need. Using semantic versioning provided basic stability, but it still had problems, like not having enough information for myself and not being easy enough for most non-technical people to understand.

I've tried messing around with different schemes, and it seems that using dates & version-specific names provides an easy-to-understand structure for most users, whilst using an X.Y.Z.Patch.Build scheme (Patch here means stability, like Beta or Alpha) provides relatively good amounts of information to suit my preferences. With this in mind, having a mix between the two would probably be best in my case. But as we know it, things aren't so simple and this still requires me to have to tweak the result until I get something that you can keep using throughout your development, that won't still need changing in the future.