У каждого пакета, который вы предоставляете, должен быть номер версии (значение атрибута Version элемента Package/Identity в манифесте приложения). Microsoft Store применяет определенные правила, связанные с номерами версий, которые работают несколько по-разному в разных версиях ОС.
Этот раздел относится к «пакетам», но, если не указано, одни и те же правила применяются к номерам версий для файлов .msix/.appx и .msixbundle/.appxbundle.
Нумерация версий пакетов Windows 10
Для пакетов Windows 10 или Windows 11 (UWP) последний (четвертый) раздел номера версии зарезервирован для использования в Магазине и должен быть оставлен равным 0 при сборке пакета (хотя магазин может изменить значение в этом разделе). Для остальных разделов должно быть задано целое число от 0 до 65535 (за исключением первого раздела, который не может быть равным 0).
При выборе пакета UWP из опубликованной отправки Microsoft Store всегда будет использовать пакет с наивысшей версией, применимый к Windows 10 или Windows 11 устройству клиента. Это дает больше гибкости и контроля над тем, какие пакеты будут предоставлены пользователям для различных устройств. Важно, что вы можете отправлять эти пакеты в любом порядке. При этом необязательно предоставлять пакеты с более поздней версией с каждой последующей отправкой.
Как сделать НУМЕРАЦИЮ страниц В ВОРДЕ с 3 СТРАНИЦЫ?
Вы можете предоставить несколько пакетов UWP с одинаковым номером версии. Однако пакеты с одинаковым номером версии не могут использовать одинаковую архитектуру, так как полное удостоверение, которое Магазин применяет для каждого пакета, должно быть уникальным. Подробнее: Удостоверение.
При предоставлении нескольких пакетов UWP, использующих один и тот же номер версии, архитектура (в порядке x64, x86, Arm, neutral) будет использоваться для определения того, какой из них имеет более высокий ранг (когда Магазин определяет, какой пакет предоставить устройству клиента). При ранжировании пакетов приложений, использующих одну версию, учитывается самый высокий ранг архитектуры в пакете: пакет для архитектуры x64 получает более высокий ранг, чем пакет, который содержит только архитектуру x86.
Это дает вам достаточно гибкости для развития вашего приложения с течением времени. Вы можете отправлять и отправлять новые пакеты, использующие более низкие номера версий, чтобы добавить поддержку Windows 10 или Windows 11 устройств, которые вы ранее не поддерживали, вы можете добавить пакеты с более высокими версиями с более строгими зависимостями, чтобы воспользоваться преимуществами оборудования или ОС, или вы можете добавить пакеты с более высокими версиями, которые служат обновлениями для некоторых или всех существующих клиентов.
В следующем примере показано, как управлять нумерацией версий для последовательной доставки запланированных пакетов пользователям.
Пример: переход к отдельному пакету для множества отправок
Windows 10 позволяет создать единую базу кода, которая работает везде. Это значительно упрощает создание кроссплатформенных проектов. Однако по ряду причин не следует объединять существующие базы кода для создания одного проекта.
Как нумеруют версии программы?
Можно использовать правила нумерации версий пакета, чтобы пользователи постепенно перешли на единый пакет для семейства универсальных устройств, предоставляя промежуточные обновления для конкретных семейств устройств (включая те, что используют API-интерфейсы Windows 10). В приведенном ниже примере показано, как одни и те же правила последовательно применяются к ряду отправок для одного и того же приложения.
— Версия пакета: 1.1.0.0
— Семейство устройств: Windows.Mobile, minVersion 10.0.10240.0
— Версия пакета: 1.1.5.0
— Семейство устройств: Windows.Universal, minVersion 10.0.10250.0
Во всех случаях устройства пользователей получат пакет, имеющий самый высокий доступный номер версии. Например, в третьей отправке выше все настольные устройства получат версию 1.1.10.0, даже если они имеют ОС версии 10.0.10250.0 или более поздней и, следовательно, могут также принимать версию 1.1.5.0. Поскольку 1.1.10.0 — наивысший доступный для них номер версии, этот пакет они и получат.
Использование нумерации версий для возврата к ранее отправленному пакету для новых приобретений
Если вы храните копии пакетов, вы сможете откатить пакет приложения в Store до более ранней версии пакета Windows 10, если вы обнаружите проблемы с выпуском. Это временный способ ограничить перебои для клиентов, пока вы занимаете время, чтобы устранить проблему.
Для этого создайте новую отправку. Удалите проблемный пакет и отправьте старый пакет в Магазин. У пользователей, которые уже получили откатываемый пакет, по-прежнему будет проблемный пакет (поскольку номер версии старого пакета меньше). Но это не позволит другим пользователям скачать проблемный пакет, при этом приложение по-прежнему будет доступно в Магазине.
Чтобы устранить проблему для клиентов, которые уже получили проблемный пакет, вы можете отправить новый пакет Windows 10, номер версии которого выше, чем неправильный пакет, как только это возможно. После сертификации этой отправки все пользователи получат обновленный пакет, так как у него будет самый большой номер версии.
Нумерация версий для пакетов Windows 8.1 (и более ранних версий) и Windows Phone 8.1
Вы больше не можете отправлять новые пакеты XAP, созданные с помощью пакета SDK для Windows Phone 8.x. Приложения, которые уже находятся в Store с пакетами XAP, продолжат работать на Windows 10 Mobile устройствах. Дополнительные сведения см. в этой записи блога.
Для пакетов .appx, предназначенных для Windows Phone 8.1, номер версии пакета в новой отправке всегда должен быть больше, чем номер пакета, включенного в последнюю отправку (или любую предыдущую отправку).
Для пакетов .appx, предназначенных для Windows 8 и Windows 8.1, то же правило применяется к архитектуре: номер версии пакета в новой отправке всегда должен быть больше номера последнего пакета для той же архитектуры, опубликованного в Microsoft Store.
Кроме того, номер версии пакетов Windows 8.1 должен быть больше, чем номера версий всех пакетов Windows 8 того же приложения. Другими словами, номер версии отправляемого пакета Windows 8 должен быть меньше номера версии любого отправляемого пакета Windows 8.1 для того же приложения.
Если приложение также содержит Windows 10 пакеты, номер версии пакетов Windows 10 должен быть выше, чем для любого из пакетов Windows 8, Windows 8.1 и (или) Windows Phone 8.1. Дополнительные сведения см. в разделе Добавление пакетов для Windows 10 в ранее опубликованное приложение.
Ниже приведены некоторые примеры того, что происходит в разных сценариях обновления номеров версий для пакетов, предназначенных для Windows 8 и Windows 8.1.
| Ничего | x86, v1.0.0.0 | x86, v1.0.0.0 на компьютерах x86 и x64 | Ничего. |
| x86, v1.0.0.0 | x64, v1.0.0.0 | v1.0.0.0 для архитектуры клиента | Ничего. Номера версий совпадают. |
| x86, v1.0.0.0 x64, v1.0.0.0 |
x64, v1.0.0.1 | v1.0.0.0 для клиентов с компьютером x86 v1.0.0.1 для клиентов с компьютером x64 |
Отсутствуют изменения для клиентов, запускающих приложение на компьютере x86. Версия 1.0.0.0 будет обновлена до версии 1.0.0.1 для клиентов, запускающих приложение на компьютере x64. Примечание Если x86-версия приложения работает на компьютере x64, приложение не будет обновлено до версии x64, если клиент не удалит и не переустановит. |
| Ничего | нейтральный, v1.0.0.1 | нейтральный, v1.0.0.1 на любых компьютерах | Ничего. |
| нейтральный, v1.0.0.1 | x86, v1.0.0.0 x64, v1.0.0.0 Arm, версия 1.0.0.0 |
v1.0.0.0 для архитектуры компьютера клиента | Ничего. Клиенты, которые используют нейтральный пакет версии 1.0.0.1, будут и дальше пользоваться этой версией приложения. |
| нейтральный, v1.0.0.1 x86, v1.0.0.0 x64, v1.0.0.0 Arm, версия 1.0.0.0 |
x86, v1.0.0.1 x64, v1.0.0.1 Arm, версия 1.0.0.1 |
v1.0.0.1 для архитектуры компьютера клиента | Отсутствуют изменения для клиентов, запускающих нейтральную версию приложения v1.0.0.1. v1.0.0.0 будет обновлена до v1.0.0.1 для клиентов, использующих версию v1.0.0.0 приложения, разработанную специально для архитектуры их компьютера. |
| x86, v1.0.0.1 x64, v1.0.0.1 Arm, версия 1.0.0.1 |
x86, v1.0.0.2 x64, v1.0.0.2 Arm, версия 1.0.0.2 |
v1.0.0.2 для архитектуры компьютера клиента | Версия 1.0.0.1 будет обновлена до версии 1.0.0.2 для клиентов, использующих любую версию 1.0.0.1 приложения, разработанную специально для архитектуры их компьютеров. |
В отличие от пакетов .appx, номера версии в любых пакетах .xap не учитываются при решении, какой пакет предоставить конкретному пользователю. Для обновления пакета .xap пользователя до более нового удалите старый пакет .xap из новой отправки.
Нумерирование версий пакетов не поддерживается для приложений MSI и EXE.
Источник: learn.microsoft.com
Программа успеха
В этой статье я хочу показать, как правильно нумеровать версии программ. Одна из самых распространенных нумераций — это нумерация в три уровня. По крайней мере я считаю ее достаточно «подробной», касательно внесения изменений в программу.
Итак, состав версионности. Это последовательность цифр, разделенных на уровни, например: 1.3.12 . Маска нумерации следующая: .. . Этот способ нумерации используется в Windows API. Существует тонкость — при изменении одного из уровней, все последующие значения уровней обнуляются. Например, цепочка версий: 1.0.1 -> 1.0.2 -> 1.1.0 -> 2.0.0
Значение уровней
— Значение этого уровня обычно меняется при исправлении каких-либо ошибок. Это значит, что для пользователя ничего не поменялось, кроме как были исправлены ошибки.
— Минорный уровень меняется, когда в программу добавляют различные плюшки, например новый функционал или элемент интерфейса. Важно то, что программа как работала так и работает, внесенные изменения ничего не сломали.
— Это самый верхний уровень. Он меняется только тогда, когда программа переписывается заново или меняются функции, которые (если менять только их) сломают целостность программы. Например, функция запуска архивации стала принимать дополнительный обязательный параметр. В этом случае, предыдущий интерфейс, который работал с этой функцией, не сможет дать ей этот параметр, что приведет к ошибке. Естественно, в этом случае делаются глобальные изменения.
Версия 1.0
Коммерческие программы начинают свою нумерацию с версии 1.0. Да, такие версии очень сырые и, скорее всего, через месяц выйдет версия 1.1, еще через месяц 1.2, а через полгода или год выйдет версия 2.0. Может это и верный путь, но на мой взгляд правильно начинать с версии 0.1 и постепенно подиматься до 1.0 — версии, готовой к работе с обычными потльзователями.
Это значит, что все мелкие ошибки исправлены и отлажена работа обычного пользователя. Да, никто не застрахован от того, что бы поймать какую нибудь ошибку, но это не повод расстраиваться и отказываться от программного продукта. Скорее всего на этот момент доблестная команда разработчиков уже трудится над ее устранением. В любом случае, если Вы первый, кто поймал такую ошибку, стоит подробно описать свои действия, которые ее вызвали и отправить на службу поддержки программы.
Заключение
Не нужно бояться «сырых» версий. Если программа достойна внимания, то и ошибки будут устраняться быстро. А Вы — обычные пользователи — самые первые помощники в улучшении качества программных продуктов. От лица всех разработчиков говорю вам СПАСИБО ЗА ВАШ ТРУД!
Поделиться
- Получить ссылку
- Электронная почта
- Другие приложения
Источник: aleksey-komov.blogspot.com