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. enter image description here
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.

  • 4
    This question might actually be better suited for Stack Overflow or Programmers.SE. There are a few different systems that you can follow - there's semantic versioning, there's the date system that Ubuntu uses, and there are many more. In your case, I'd probably use a date system for the main releases, and place the developer data elsewhere. – lunchmeat317 Dec 1 '14 at 20:32
  • 2
    @lunchmeat317 We have systems that works for engineering. This is really about what format would give the users most comfort. – paparazzo Dec 1 '14 at 20:47
  • 2
    Think about how easy it is to communicate the informtion down the phone when someone on the helpdesk asks 'what version are you using ?'... so you want to write it in a format which is easy for users to read without making mistakes. – PhillipW Dec 2 '14 at 11:46
  • 3
    Personally, I see high version numbers as a bad thing. About four years ago I was using Firefox 2. Now we're on Firefox 33. What the hell have they been doing that takes 31 major version numbers and still doesn't work properly? I'll just stick with my IE11, thanks! – Niet the Dark Absol Dec 2 '14 at 16:19
  • 4
    Whatever you do, please do not introduce something like Alliterated Animals, Large Cats, US National Parks or Candy code names to the public. – Crissov Dec 2 '14 at 18:55

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


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.

  • There are several good answers here but I am going to accept this. A proposed standard is more than no standard. And it works for me (engineering). If marketing want something else then fine will just have an internal and external version. – paparazzo Dec 1 '14 at 20:44
  • 3
    en.wikipedia.org/wiki/Software_versioning covers a bit more on this, too. Some systems have four numbers, where the fourth number describes a build or revision within a patch (as named here). Having 2-4 numbers is fairly common. The only other common theme seems to be something like YYYY.MMDD.BB, basically a date followed by the build for that date. This semantic has the bonus of not divulging the "beta-ness" of a particular release, since it only describes the day and relative time of day (1 came before 2). Internally documented, this can be useful. – phyrfox Dec 2 '14 at 7:43
  • I'd version a program like this, but I'm not sure it works very well for a dataset. – Michael Hampton Dec 3 '14 at 4:45
  • 1
    We are using semantic versioning for just everything here. From documents and settings to database versions. It's very usefull when everyone knows what each number means. You just look at the number and know what to expect. It's just a matter of convention. – t3chb0t Dec 3 '14 at 9:42
  • The wording "bug fix" struggles me a bit here. I would rename it "backward + forward compatible change", which would then include performance or GUI improvements, that do not add features and functionality; at least not with a universally aggreed upon terminology. – phresnel Dec 3 '14 at 13:35

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).

  • 1
    +1 This actually answers the OP's focus on user experience/preference. – Chris Schiffhauer Jan 29 '15 at 4:15

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).

  • 2
    Our users do care about the number. Like I said once we changed the informal format to indicate to installers a special requirement and users raised all sorts of speculation. – paparazzo Dec 1 '14 at 19:17
  • Yeah. I'm hoping that some people have run across research dealing with this issue. If you have time it would be interesting to know (in greater depth) what the users were concerned about. Were they worried that it wouldn't be backward compatible? How did they notice that the version changed? (Did you stress the change with an email: "Dear users we're changing your mission critical software ..." or did you simply role out the new version? – Mayo Dec 1 '14 at 19:23
  • Oh man, it get complex but is is part of UX so I will add it to the question – paparazzo Dec 1 '14 at 19:28
  • Well, I was concerned when Firefox switched to the larger version steps back then ... mostly because the inceased version number no longer allowed one to guess the impact e.g. on a developer was – Hagen von Eitzen Dec 1 '14 at 22:31
  • No doubt. :-) I was developing during the IE/Netscape 4.x wars. I was, of course, very concerned about browser versions. But my grandmother wasn't and, at my job, the receptionists and HR staff weren't either. – Mayo Dec 1 '14 at 22:38

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: instead of 1.2-a1 instead of 1.2-b2 (beta with some bug fixes) instead of 1.2-rc3 (release candidate) instead of 1.2-r (commercial distribution) instead of 1.2-r5 (commercial distribution with many bug fixes)

Ref: Software Versioning

  • Users are already insulated from alpha - release. I am not asking for users to be aware of database schema and it is not part of the current published version. All we really have is release candidate that will be limited to specific customers and final release. – paparazzo Dec 1 '14 at 19:50
  • @BennySkogbergMCSA - What do you think of my answer compared to what you are saying. I do like what you are quoting, but it's not too informational at-a-glance, as it would be in our specific scenario. I'm just curious. I do like your quoted standard though for sure. – Code Maverick Jan 14 '15 at 21:22

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.


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.

  • I am with you but what I am seeing on a all the products I use are long version numbers. Is that what a user is expecting? Like telephone number is ###-###-#### and a SSN is ###-##-####. Was there any UX to that or just what worked for the technology. – paparazzo Dec 1 '14 at 20:13
  • @Blam As far as I know that's more common the "nerdier" your platform. E.g. Linux is known for insanely long numbers, Windows apps are a bit shorter, Mac is 2 or 3 components with at most 2 digits. (Of course ported software muddies the statistic a bit and outliers exist) But look at Windows itself: End users get "Windows 95", maybe with "Service Pack 1" appended. That's it. The internal engineering version is completely unrelated (what was it -- 5.0.3?) – uliwitness Dec 2 '14 at 13:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.