What version number format would give users the most reassurance?

Question

I am trying to figure out a good, meaningful version numbering system for an application and the data sets the application uses. The critical thing is that the versioning system has to give the user comfort. What version formats would do that? Should I start on like 3.025 vs 3.001 so users don't have the perception they are on beta code.

(the rest of this question contains background on the application in question, version numbers used, and examples of how a couple popular products present their version numbers).

two associated but distinct components: app and data set

The app has releases at least twice a year, during which the version number should change. The app works with a data set. A data set has about a two year life; it's rarely upgraded in less than 2 years unless there is feature the customer specifically needs. The app version and the data set version have pretty much nothing to do with each other - a given customer can often be on separate versions with different data sets.

It is important for the customer and support to know what version they are on. And user admin actually would benefit from know a schema change as they dump data. Customer support needs the version numbers to diagnose and reproduce bugs. Version numbers also signal enhancements to the product so that customers know it's time to upgrade.

Given the information below, what versioning technique would be best for my product? Is there a version format that brings confidence to a user?

current version format: #.##[a-z[_featurecode]]

Our version is represented in the format #.##[a-z] and if there is customer specific feature we have a code for that with an _.

Internally we really need 5 parts but they don't need to be communicated to the user

• version of the software we use to build the software
• version of the database schema
• version of the code
• indication of customer specific release
• version of bug fix

We once made the mistake of putting something to describe the release in the version and that raised all kinds of speculation - we learned never to do that again.

Microsoft versioning

Microsoft has these really long versions.
Long version numbers seem to be the standard - even in end user products.

chrome versioning

Look at Chrome stable channe

Should we avoid like a 3.001 and start on like 3.321 so people don't think I have a beta version?

out of scope

I am not looking for input on providing feature lists and bug lists as part of the release.

Answer 1

There may not be a real standard with regards to versioning, but I believe this ideology is straightforward, useful, and picking up traction: Semantic Versioning

Summary

Given a version number MAJOR.MINOR.PATCH, increment the:

1. MAJOR version when you make incompatible API changes,
2. MINOR version when you add functionality in a backwards-compatible manner, and
3. PATCH version when you make backwards-compatible bug fixes.

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

There's much more information (omitted for brevity) with regards to the additional labels that covers more complex scenarios on the site.

Answer 2

In my custom assembly versioning world, I've found that you have 2 views on what it needs to look like:

1. Users prefer shorter versioning with a format of <Major>.<Minor>: 8.0, 8.1, 8.3, etc.

2. Developers and other technical personnel need a little more info than that. For example, we use TFS for source control, so it'd be nice to know what changeset number we are on. It'd be nice to know the date, and maybe even the daily build number. So what I've done for us is create the following format:<Major>.<Changeset Number>.<YY DayOfYear>.<Sequential Daily Build Number>

So details look would be something like:

Major    Changeset Number     YY DayOfYear     Sequential Daily Build Number
-----    ----------------     ------------     -----------------------------

16       C4952                14 335           7

Thus, when you parse everything out, you'd end up with a File Assembly Version of 16.4952.14335.7.

That could be coded to be displayed in a DEBUG mode or for only the IT group, or whatever, but at the very least, it would be on Details tab of the Properties of the assembly (DLL file).

Answer 3

This is a good question. I faced that a while back (summer of 2012) and googled for answers and didn't find any. It's really a multi-part question.

1. Do users of an existing system care about the version number?
2. Are users annoyed when the version number gets unwieldy.
3. When bringing out a new product should one begin at a number besides 1.0 as you don't want users thinking that they are getting a beta version.

We solved it by asking these questions to everyone in the company (as well as people associated with the company) from receptionists to developers to sales staff to accountants.

In essence few people ever cared or paid attention except when prompted.

EX: "You need version X.YZ to use feature F.

How many of us know which version of anything we're using? Microsoft, Google and other companies update their products constantly. I'm using Chrome Version 33.0.1750.154 m. I wouldn't know, or care, if tomorrow it was 33.0.1876.234 b.

In short nobody cared about Point 1 or Point 2 but Point 3 was discussed in depth.

We solved point 3 by using our internal version control numbers when released, so the product was a version 2.6 (or something like that).

Answer 4

Following standards is always a good thing, but I think you try to build in too much meaning in the versioning. Keeping it simple toward end users is what you need, keeping track of database version, code release, IDE version and customer specific release (through branching?) is asking too much IMHO. This is something you should keep track of in your quality system, since every release i unique - even if it's branched.

Designating development stage

Some schemes use a zero in the first sequence to designate alpha or beta status for releases that are not stable enough for general or practical deployment and are intended for testing or internal use only.

It can be used in the third position:

0 for alpha (status)

1 for beta (status)

2 for release candidate

3 for (final) release

For instance:

1.2.0.1 instead of 1.2-a1

1.2.1.2 instead of 1.2-b2 (beta with some bug fixes)

1.2.2.3 instead of 1.2-rc3 (release candidate)

1.2.3.0 instead of 1.2-r (commercial distribution)

1.2.3.5 instead of 1.2-r5 (commercial distribution with many bug fixes)

Ref: Software Versioning

Answer 5

While semantic versioning is a nice idea, in practice it can suck, mainly because it all hinges on individuals' ideas of what warrants a "version bump".

You can restore some sanity by sticking to a more strict system, like what Aaron Brooks suggests, but it's more work to set up at the beginning.

But for version numbers that you show your customers, I would take a hint from hardware manufacturers like Samsung, Google, and Apple: use whole numbers. Nexus 5, iPad 2, etc. Actually, take another lesson from Apple and don't call something the "new something".

...Or even Roman numerals, to make it look more wrong when you stray away from whole numbers.

Answer 6

Mayo gives a lot of good points. Beyond that, I'd like to point out that there are actually 2 kinds of version numbers: Ones for internal use by the computer (which can be as horrible and as long as you like) and user-visible ones.

Users do not want to care about version numbers, they want their stuff to work. They do not time to find out what scheme you are using and what each part of your version number means. So, when they have to be aware about a version number, make sure it is short, simple, and easy to tell whether one is newer than the other.

Ideally, if you have only very few releases per year, you'd just use a single number. If that's not workable for your use case, a single number plus a bugfix number. This also works well for marketing, as there is less noise, and more punch whenever the number does change.