App Store 版本号 - 更改方案/最佳实践
我们正在考虑更改 iOS 应用程序下一个版本中的版本号，从使用传统的 Major.Minor.Patch 版本号方案改为使用基于日期的方案（例如 2012.month.patch），以更好地向用户反映当前版本的版本号。该应用程序。
Apple 在 iTunes Connect 中的唯一版本号指导如下：
您要添加的应用程序的版本号。应遵循编号 典型的软件版本控制约定（例如，1.0 或 1.0.1 或 1.1）。
我的问题 - 他们执行这个传统计划吗？
使用基于日期的方案有什么缺点吗？
更改已广泛部署的应用程序上的方案是否可能会出现任何问题？
更新：为了解释更多采用基于日期的版本控制方案的理由...相关应用程序的更新主要是为了反映每年添加几次的新数据集。对于用户来说，知道版本 2012.2 具有当前数据非常有用 - 版本 2.6 没有传达这一点。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
苹果方案通常是强制执行的，因为你的包会被检查两次以获得正确的版本号（一次在验证时，一次在上传时）。即使不是苹果公司，也是普遍接受的传统。此外，如果您可以仅使用内部版本号字段，为什么需要超出建议的小数位数呢？
无论如何，只有一个问题。有时，iTunes Connect 在处理小数点后两位数时会遇到问题。我的意思是，V1.1 和 V1.10 有时显示为相同版本（因为零被忽略）。但是，V1.11 没问题。
根据你的建议，这看起来有点奇怪，但我会继续尝试。应用程序商店不会显着地显示版本号（软件更新期间除外，即使如此，它也是一个副标题），所以我敢打赌它可能会直接溜过去。如果需要，只需修改应用程序的名称以反映年份即可。
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.
根据我的经验，除了第一个版本不低于 1.0 并且您不能发布较低编号的版本之外，他们不会强制执行它。
传统方案的优点是它专注于可以按照您的节奏更新的功能，而不是总是滴答作响且变化太快的日期。很容易看出该版本与其他版本的关系以及较短的使用日期。
你为什么想要这样做？如果您在 2012.02.08 向应用商店提交，但直到 2 月 15 日才获得批准，那么立即就会出现差异。应用程序商店列出了应用程序上次更新的日期，您的用户可以阅读该日期或您的网站。
如果您定期更新它，并且他们下载更新，那么我确信他们会收到您的应用程序正在经常更新的消息。我当然会注意到应用程序何时更新。除了在下载时或在应用程序内实际看到版本号之外，将版本号更改为日期并不能帮助他们知道它经常更新。
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.
在做了一些研究以提交我的第一个版本之后，我正在写这篇文章。
应用的首次上传不能低于1.0（不允许测试版想法）
每次后续上传都应至少增加一
允许的最大子版本格式为XXX（其中X只能是数字）
无字母
确保 Info.plist 文件中所有版本相关参数中仅遵循一个版本号，然后再存档上传到应用商店
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
我想对此发表评论说使用年.月.日版本控制方案很好。
我检查了我的手机，看看谁在做类似的事情，这是我发现的：
I wanted to comment on this to say that using a year.month.day versioning scheme is fine.
I checked my phone to see who's doing something similar and here's what I found: