Есть ли причина использовать один стиль управления версиями над другим для .NET-сборок ????major.minor.build.revision стиль версии vs year.month.day.whatever стиль версии
Я хотел бы знать, есть ли какие-либо преимущества/недостатки в использовании любого стиля, кроме вкуса.
Преимущество в том, что вы получаете как увеличивающийся номер версии , так и кодируете временную метку.
Преимущество использования более традиционных номеров заключается в том, что людям легче понять. Мы все знаем примерно то, что означает «v2.1», например.
В общем, я предлагаю использовать время, потому что добавленная информация полезна. Преимущество других номеров - только для маркетинга, и для этого вы все равно можете это сделать.
Например, почему бы и нет, a la "v.2.1.20090214." Теперь у вас есть маркетинг в разделе major.minor и утилите в разделе «сборка».
Я просто оставляю AssemblyVersion на «1.0. *» И удаляет любую AssemblyFileVersion.
Затем я могу увеличить номера версий майора и младшего, как представляется, соответствующим образом, и автоматически установить базовую сборку и ревизию DateTime.
Если у вас нет альтернативных инструментов сборки, которые контролируют номер сборки и ревизии в соответствии с какой-либо другой схемой, я не вижу реального преимущества для их настройки вручную.
Я делаю то же самое. –
Я использую некоторые скрипты сборки, которые обновляют мою ревизию на основе пересмотра SVN. Это делает тривиальным отслеживание dll обратно к исходному коду, который его создал.
Время сложнее; вы должны начать искать в области истории - где, поскольку большинство инструментов управления версиями имеют возможность «получить ревизию».
Почему именно? Вы можете использовать такой формат, как Major.Minor.YYMMDD.Revision, и получить лучшее из обоих миров.
Редактировать Как указывалось в комментариях, иногда диапазон каждого поля ограничен. В этом случае вы можете использовать Major.Minor.YMMDD.Revision.
Надеюсь, вы измените второстепенную версию, по крайней мере, каждые 10 лет!
, пожалуйста, исправьте меня, если я ошибаюсь, но согласно MSDN на странице «http://msdn.microsoft.com/en-us/library/system.reflection.assemblyversionattribute.aspx» каждый компонент должен быть числом от 0 до 65535. YYMMDD будет слишком большим. «Major.Minor.YYYY.MMDD» подходит, но выглядит следующим образом :-( – angrifel
Одним из недостатков нумерации версий на основе даты является отрицательный восприятие старого программного обеспечения.
Хотя, я использую его в любом случае, потому что он очень хорошо подходит для моих проектов.
Не всегда недостаток. Это негативное восприятие можно использовать для продажи вашей новой версии. –
Использование времени/даты имеет еще один (помимо тех, которые уже упоминались в других ответах здесь) недостаток:
если вы команда разработчиков распространяются на различные зоны времени, вы никогда не будете уверены в том, какая из две версии, построенные за один час, являются более новыми. Если вы также не изменяете часовой пояс или не заставляете дату/время находиться в, например, ВРЕМЯ ПО ГРИНВИЧУ.
Преимущество использования схемы 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, которая может иметь некоторые функции/улучшения, отсутствующие в ней.
Если вы используете дату в качестве номера версии, ради милосердия используйте формат YYYYMMDD. Это единственное, что почти каждый может читать однозначно, и имеет преимущество лексической сортировки в правильном порядке. – Evan
(Для некоторых из нас некоторые страны записывают свои даты в формате ММ-ДД-ГГГГ, а большая часть остального здравого слова записывает их в формате DD-MM-YYYY или YYYY-MM-DD.) – Evan
Обратите внимание, что на Win32 (и, следовательно, на .NET) номера версий имеют 16-разрядный предел для каждого компонента, поэтому 20090214 как один компонент невозможен. –