App Store Version Numbers - Changing Scheme / Best Practices

Question

We are contemplating changing the version number in the next release of an iOS app from using the traditional Major.Minor.Patch version number scheme to instead use a date based scheme such as 2012.month.patch to better reflect to our users the currency of the app.

Apple's only version number guidance in iTunes Connect is as follows:

The version number of the app you are adding. Numbering should follow typical software versioning conventions (for example, 1.0 or 1.0.1 or 1.1).

My question - do they enforce this traditional scheme?

Is there any downside to using a date based scheme?

Are there any gotchas that might emerge from changing schemes on an app that has already been widely deployed?

Update: To explain a bit more of the justification for going to a date-based versioning scheme... The apps in question are updated primarily to reflect new datasets being added a few times a year. It is useful for a user to know that version 2012.2 has current data - version 2.6 does not convey that.

Answer 1

The apple scheme is generally enforced, seeing as your bundle is checked twice for the proper version number (once at validation, once at upload). And if not by apple, by general accepted tradition. Besides, why would you need to go beyond the recommended decimal places if you could just use the build number field for that?

Anyways, there is but one gotcha. Sometimes, iTunes Connect has trouble with double digit numbers in decimal places. What I mean, it that V1.1 and V1.10 sometimes show up as the same version (because the zero is ignored). But, V1.11 is fine.

As per your suggestion, it would seem slightly outlandish, but I would go ahead and try it. The app store does not prominently display version numbers (except during software updates, and even then, it's a subtitle), so I'll bet it could just slip right by. If you need to, just amend the name of the app to reflect the year.