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