Номера версий App Store - изменение схемы / лучшие практики

Question

Мы планируем изменить номер версии в следующем выпуске приложения для iOS, не используя традиционную схему номеров версий Major.Minor.Patch, чтобы вместо этого использовать схему на основе даты, например 2012.month.patch, чтобы лучше отражать мнение наших пользователей валюта приложения.

Единственное руководство Apple по номеру версии в iTunes Connect выглядит следующим образом:

Номер версии приложения, которое вы добавляете. Нумерация должна следовать типичные соглашения о версии программного обеспечения (например, 1.0 или 1.0.1 или 1.1).

Мой вопрос - они применяют эту традиционную схему?

Есть ли недостатки в использовании схемы, основанной на дате?

Есть ли какие-либо ошибки, которые могут возникнуть при изменении схем в приложении, которое уже широко развернуто?

Обновление: Чтобы объяснить немного больше обоснования перехода на схему управления версиями на основе даты ... Соответствующие приложения обновляются в основном для отражения новых наборов данных, добавляемых несколько раз в год. Пользователю полезно знать, что в версии 2012.2 имеются текущие данные - в версии 2.6 это не передается.

Answer 1

Схема Apple, как правило, применяется, поскольку ваш пакет дважды проверяется на наличие правильного номера версии (один раз при проверке, один раз при загрузке). А если не по яблоку, то по общепринятой традиции. Кроме того, зачем вам выходить за пределы рекомендуемых десятичных разрядов, если вы можете просто использовать для этого поле номера сборки?

В любом случае, есть только одна ошибка. Иногда в iTunes Connect возникают проблемы с двузначными числами в десятичных разрядах. Что я имею в виду, это то, что V1.1 и V1.10 иногда отображаются как одна и та же версия (потому что ноль игнорируется). Но, V1.11 в порядке.

Согласно вашему предложению, это может показаться немного странным, но я бы попробовал. Магазин приложений не отображает номера версий (кроме как во время обновлений программного обеспечения, и даже в этом случае это субтитры), так что, держу пари, он может просто проскочить. Если вам нужно, просто измените название приложения, чтобы отразить год.

Answer 2

По моему опыту, они не применяют его, за исключением того, что первая версия не меньше 1.0, и вы не можете выпустить версию с меньшим номером.

Преимуществом традиционной схемы является то, что она фокусируется на возможностяхобновляется в вашем темпе вместо даты, которая всегда отсчитывает время и меняется слишком быстро.Легко сказать, где релиз соответствует другим релизам и короче, используя даты.

Зачем вам это нужно?Если вы отправите 2012.02.08 в магазин приложений, но он не будет утвержден до 15 февраля, сразу же возникает несоответствие.В магазине приложений указана дата последнего обновления приложения, ваши пользователи могут перейти на этот сайт или прочитать его.

Если вы регулярно обновляете его и они загружают обновления, то я уверен, что они получат сообщение о том, что ваше приложение часто обновляется.Я конечно замечаю, когда приложения обновляются.Помимо фактического просмотра номера версии при загрузке или в приложении, изменение номера версии на даты не помогает им узнать, что оно часто обновляется.

Answer 3

Проведя некоторые исследования, чтобы представить мою первую сборку, я пишу это.

Первая загрузка приложения не может быть меньше 1.0 (идеи бета-версии не допускаются ) Каждая последующая загрузка должна быть увеличена как минимум на единицу

Максимально допустимый формат вспомогательной версии XXX (где Xтолько цифры) Нет алфавитов

Убедитесь, что во всех связанных с версиями параметрах в файле Info.plist используется только один номер версии перед архивированием для загрузки в магазин приложений