Majoring.minor.build.revision стиль управления версиями против year.month.day. независимо от стиля управления версиями

Question

Есть ли причина использовать один стиль управления версиями поверх другого для сборок .NET ????

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

Answer 1

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

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

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

Например, почему бы не иметь оба, а-ля "v2.1.20090214". Теперь у вас есть маркетинг в разделе major.minor и утилита в разделе «build».

Answer 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, в которой могут отсутствовать некоторые функции / улучшения.

Answer 3

Я просто оставляю AssemblyVersion на «1.0. *» И удаляю любой AssemblyFileVersion.

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

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

Answer 4

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

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

Answer 5

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

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

Answer 6

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

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

Answer 7

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

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

Надеюсь, вы измените младшую версию хотя бы раз в 10 лет!