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.
In my experience they do not enforce it except that the first version is not less than 1.0 and you cannot release a lower numbered version.
The upside to the traditional scheme is it focuses on features which may be updated at your pace instead of the date which is always ticking away and changing much too fast. It is easy to tell where the release fits in relation to the other releases and shorter using dates.
Why would you want to? If you submit 2012.02.08 to the app store but it is not approved until the 15th of February then immediately there is a disparity. The app store lists the date the app was last updated, your users can go read that or your website.
If you regularly update it, and they download the updates, then I’m sure they’ll get the message that your app is being updated frequently. I certainly notice when apps are updated. Other than actually seeing the version number while downloading it or within the app, changing the version number to dates doesn’t help them know it is updated frequently.