Основной принцип, который я бы предложил: используйте самую простую из возможных схем.
Подумайте об упрощении для себя, своего отдела маркетинга и своих пользователей.
Когда вы делаете релиз, увеличиваете основной / вспомогательный номер версии, а затем ставьте его на всех ваших компонентах. Таким образом, в версии 10.1 все ваши сборки будут иметь номера версий 10.1.xx.yy
Тогда, если вы действительно хотите усложнить ситуацию с разными версиями в выпуске (например, для небольших исправлений / обновлений, разных пользовательских вариантов или только для внутренних ежедневных сборок или сборок CI), тогда используйте поля xx.yy. (Во многих случаях вы можете заставить компилятор автоматически заполнять эти два поля, например, датой / временем компиляции).
Это означает, что у вас есть значимая «маркетинговая версия», которая на самом деле связана с вашими версиями кода (так что вы и маркетинг можете говорить о конкретном выпуске без какой-либо путаницы) и можете добавить дополнительную информацию (например, дату сборки) если (и только если) необходимо на стороне разработчика.
редактировать: P.S. Даже если компонент не изменяется, перестройте его с новым номером версии. Попытка отследить сто несинхронизированных номеров версий - это кошмар, которого можно избежать.