versioning - What version number format would give users the most reassurance?

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

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.