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.
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.
After doing some research to submit my first build I am writing this.
First upload of the App can not be less than 1.0 ( no beta version ideas allowed) Every subsequent upload should be incremented by one at the least
Maximum sub-version format allowed is X.X.X (where X can only be numbers) No alphabets
Make sure only one version number is followed in all the version related parameters in Info.plist file before archiving to upload to the app store
来源：https://stackoverflow.com/questions/9205098/app-store-version-numbers-changing-scheme-best-practices