App Store版本号 – 更改计划/最佳实践

我们正在考虑使用传统的Major.Minor.Patch版本号scheme更改下一版iOS应用程序的版本号，以改用2012.month.patch等基于date的scheme，以更好地反映我们的用户的货币该应用程序。

iTunes Connect中唯一的版本号指南如下：

您要添加的应用程序的版本号。编号应遵循典型的软件版本控制惯例（例如，1.0或1.0.1或1.1）。

我的问题是 – 他们执行这个传统的scheme吗？

使用基于date的scheme有什么缺点吗？

在已被广泛部署的应用程序中，是否有可能出现更改scheme的问题？

更新：为了解释更多的基于date的版本控制计划的理由…所述的应用程序主要是为了反映每年新增几次数据集而进行更新。对于用户来说知道版本2012.2具有当前数据是有用的 – 版本2.6不能expression这一点。

根据我的经验，除了第一个版本不低于1.0，并且不能释放较低编号的版本，他们不会执行它。

传统scheme的优势在于它的重点是可以按照你的步调更新的function，而不是总是在慢慢变化的date。很容易判断发行版与其他发行版的关系，并缩短使用date。

你为什么要？如果您将2012.02.08提交给app store，但直到2月15日才会批准，那么立即就会出现差异。 app store列出应用上次更新的date，您的用户可以阅读该文件或您的网站。

如果您经常更新它，并且下载了更新，那么我相信他们会收到消息说您的应用程序正在经常更新。我当然注意到当应用程序更新。除了实际上在下载版本号或在应用程序内看到版本号时，将版本号更改为date并不能帮助他们知道经常更新。

苹果计划通常是强制执行的，看你的包是检查两次正确的版本号（一旦validation，一次上传）。如果不是苹果，按照普遍接受的传统。此外，为什么你需要超越build议的小数位，如果你可以只使用内部编号字段呢？

反正，只有一个问题。有时，iTunes Connect有小数点后两位数的问题。我的意思是，V1.1和V1.10有时显示为相同的版本（因为零被忽略）。但是，V1.11很好。

根据你的build议，这似乎有些古怪，但我会继续尝试。应用程序商店不会显着地显示版本号（除了在软件更新期间，即使这样，它是一个副标题），所以我敢打赌，它可能会滑落。如果需要，只需修改应用的名称以反映年份。