Major.minor.build.revision стиль версии vs year.month.day.whatever стиль версии

Ответ 1

Преимущество времени в том, что вы получаете как увеличенный номер версии, так и кодируете временную метку.

Преимущество использования более традиционных чисел заключается в том, что людям легче понять. Мы все знаем примерно то, что означает "v2.1", например.

В общем, я предлагаю использовать время, потому что добавленная информация полезна. Преимущество других номеров - только для маркетинга, и для этого вы все равно можете это сделать.

Например, почему бы и нет, a la "v.2.1.20090214". Теперь у вас есть маркетинг в разделе major.minor и утилите в разделе "сборка".

Ответ 2

Преимущество использования схемы major.minor.revision - семантика. Там есть способ обновления каждого из этих чисел:

Значительное изменение количества означает, что новая версия несовместима со старой, и любая зависимая от предыдущей версии потребует изменений кода для обновления до нового пакета.

Незначительное изменение номера означает, что новая версия обратно совместима с предыдущей версией, но имеет значительные улучшения по сравнению с предыдущей версией.

Номер версии обновляется всякий раз, когда исправление применяется к сборке, так что оно не приводит к изменению совместимости или не вводит новые функции.

При указании зависимостей вы можете сказать, что вы зависите от foo-1.0.0 - foo-1.99.999, и будьте уверены, что вы не закончите обновление пакета, которое нарушит ваше приложение.

Если вы начали с более высокой младшей версии зависимости, скажем, foo-1.4.22, вы должны указать зависимость как foo-1.4.22 - foo-1.99.999, так что вы не закончите установку версия старше 1.4.x, которая может иметь некоторые функции/улучшения, отсутствующие в ней.

Ответ 3

Я просто оставляю AssemblyVersion в "1.0. *" и удаляю любую AssemblyFileVersion.

Затем я могу увеличить номера версий Major и Minor, как кажется, подходящим, и автоматически установить базовую сборку и ревизию DateTime.

Если у вас нет альтернативных инструментов сборки, которые управляют номером сборки и ревизии в соответствии с какой-либо другой схемой, я не вижу реального преимущества для их настройки вручную.

Ответ 4

Использование времени/даты имеет еще один (кроме уже упомянутых в других ответах здесь) недостаток:

если команда разработчиков распределена по разным часовым поясам, вы никогда не будете уверены, что одна из двух версий, построенных за один час, является более новой. Если вы также не изменяете часовой пояс или не заставляете дату/время находиться в, например, GMT.

Ответ 5

Я использую некоторые скрипты сборки, которые обновляют мою ревизию на основе пересмотра SVN. Это делает тривиальным отслеживание dll обратно к исходному коду, который его создал.

Время сложнее; вы должны начать искать в области истории - где, поскольку большинство инструментов управления версиями имеют возможность "получить ревизию".

Ответ 6

Зачем выбирать? Вы можете использовать такой формат, как Major.Minor.YYMMDD.Revision, и получить лучшее из обоих миров.

Edit Как отмечалось в комментариях, иногда диапазон каждого поля ограничен. В этом случае вы можете использовать Major.Minor.YMMDD.Revision.

Надеюсь, вы измените второстепенную версию, по крайней мере, каждые 10 лет!

Ответ 7

Одним из недостатков нумерации версий на основе дат является негативное восприятие старого программного обеспечения.

Хотя, я все равно использую его, потому что он очень хорошо подходит для моих проектов.