Сверху моей головы существует несколько способов справиться с этим, и ни один из них не является «правильным». Все зависит от ваших процессов выпуска и того, как вы хотите представить свой продукт клиенту.
Если вы протестируете и отпустите свои компоненты в замке, вероятно, полезно, чтобы ваши номера версий двигались в блокировке. Таким образом, всем известно, что версия 1.4.4 пользовательского интерфейса для ПК знает, что версия 1.4.4 iPhone должна иметь одинаковые функции.
Если ваши пользовательские интерфейсы могут иметь разные функции в разное время (спешите выпустить функцию на рабочем столе, но она может ждать iPhone), то, очевидно, у вас будут разные номера версий. Однако я бы рекомендовал, чтобы основные выпуски должны были повторно синхронизировать номера версий с X.0.0.
Вы можете сделать это несколько спорным путем, чтобы продукты соответствовали графику их собственных версий для обычной части <major>.<minor>.<maintenance-patch> и включали номер сборки в качестве последнего компонента. Таким образом, вы получите <major>.<minor>.<patch>.<build>. Преимущество этого подхода заключается в том, что вы можете выпускать различные компоненты в разное время, и вы все равно получаете отчет о построенной им базе. В этом случае номер сборки должен быть монотонно увеличивающимся числом, обычно управляемым централизованной системой сборки. Обычно мне не нравится оставлять контроль над номерами версий в системе сборки, так как может быть много чувствительности к предмету с маркетингом, управлением линейкой продуктов и т. Д. Наличие номера сборки очень полезно, но сделать это наименее важная часть номера версии.
Одна вещь, которую я порекомендую, заключается в том, что ваш процесс сборки «построил мир» за один раз. Очевидно, что вы захотите создать отдельные пользовательские интерфейсы для удобства разработчиков, но намного проще управлять отдельными процессами ночной сборки, которые строят все возможные компоненты со всеми их зависимостями за один снимок. И убедитесь, что все пользовательские интерфейсы используют те же, текущие, общие компоненты в вашем репозитории. Если им нужны разные версии общих компонентов, вы просите мир о боли, когда пытаетесь правильно построить все. Затем вы получаете отдельные сборки для различных компонентов, которые запускают сборку пользовательских интерфейсов и т. Д.