Для этого есть два хороших ответа (плюс множество личных предпочтений, см. Комментарий гизмо о религиозных войнах)
Для общедоступных приложений стандартный Major.Minor.Revision.Build лучше всего работает IMO - публичные пользователи могут легко определить, какая версия программы у них есть, и в какой-то степени, насколько устарела их версия.
Для в домашних приложениях, где пользователи никогда не запрашивали приложение, развертывание выполняется ИТ-отделом, а пользователи будут вызывать службу поддержки, я обнаружил, что Year.Month.Day.Build работать лучше во многих ситуациях. Таким образом, этот номер версии можно декодировать, чтобы предоставить справочной службе более полезную информацию, чем общедоступная схема номеров версий.
Тем не менее, в конце дня я бы сделал одну рекомендацию превыше всего - используйте систему, которую вы можете поддерживать последовательной . Если есть система, которую вы можете настроить / написать сценарию для автоматического использования каждый раз, используйте эту .
Худшее, что может произойти, это то, что вы выпускаете двоичные файлы с тем же номером версии, что и предыдущие - недавно я имел дело с автоматическими сообщениями об ошибках сети (кто-то использует приложение) и пришел к выводу, что Year.Month Номера версий .Day.Build, показанные в дампах ядра, где они даже не обновляются удаленно до самого приложения (само приложение использовало заставку с действительными числами - что, конечно, не взято из двоичного файла, как можно предположить). В результате я не могу узнать, происходят ли аварийные дампы из 2-летнего двоичного файла (что указывает номер версии) или из 2-месячного двоичного файла, и, таким образом, нет никакого способа получить правильный исходный код (также нет никакого контроля исходного кода! )