Aus der Spitze meines Kopfes gibt es eine Reihe von verschiedenen Möglichkeiten, damit umzugehen, und keiner von ihnen ist "richtig". Es kommt auf Ihre Freigabeprozesse an und wie Sie Ihr Produkt dem Kunden präsentieren möchten.
Wenn Sie Ihre Komponenten im Lockstep testen und freigeben, ist es wahrscheinlich nützlich, dass sich Ihre Versionsnummern auch im Lockstep bewegen. Jeder weiß, dass Version 1.4.4 der Desktop-Benutzeroberfläche weiß, dass die 1.4.4 iPhone-Version die gleichen Funktionen haben sollte.
Wenn Ihre UIs zu unterschiedlichen Zeiten verschiedene Funktionen haben können (Sie müssen schnell eine Funktion auf dem Desktop freigeben, aber sie können auf das iPhone warten), dann haben Sie natürlich andere Versionsnummern. Ich würde jedoch empfehlen, dass Major Releases die Versionsnummern auf X.0.0 neu synchronisieren sollten.
Sie können dies etwas falsch machen, indem Sie die Produkte ihrem eigenen Versionsplan für den üblichen <major>.<minor>.<maintenance-patch> Teil folgen lassen und die Build-Nummer als letzte Komponente angeben. Sie würden also mit <major>.<minor>.<patch>.<build> enden. Der Vorteil dieses Ansatzes besteht darin, dass Sie verschiedene Komponenten zu unterschiedlichen Zeiten freigeben können, und Sie erhalten immer noch die Aufzeichnung des Builds, aus dem sie stammt. In diesem Fall sollte die Build-Nummer eine monoton steigende Zahl sein, die typischerweise von einem zentralisierten Build-System verwaltet wird. Normalerweise lasse ich die Versionsnummern nicht gerne an das Build-System, da es mit Marketing, Produktlinienmanagement usw. sehr viel Feingefühl geben kann. Die Build-Nummer ist sehr nützlich, aber mach sie am wenigsten wichtiger Teil der Versionsnummer.
Eine Sache, die ich empfehlen werde, ist mit Ihrem Build-Prozess "build the world" auf einmal. Offensichtlich sollten Sie das Erstellen der separaten Benutzeroberflächen für die Bequemlichkeit von Entwicklern ermöglichen, aber es ist viel einfacher, einzelne nächtliche Build-Prozesse zu verwalten, die alle möglichen Komponenten mit allen Abhängigkeiten auf einmal erstellen. Stellen Sie sicher, dass alle Benutzeroberflächen die gleichen, aktuellen, freigegebenen Komponenten in Ihrem Repository verwenden. Wenn sie verschiedene Versionen von gemeinsam genutzten Komponenten benötigen, fragen Sie nach einer Welt voller Verletzungen, wenn Sie versuchen, alles korrekt zu erstellen. Sie haben dann am Ende unterschiedliche Builds für die verschiedenen Komponenten, die Builds der UIs etc. auslösen.