управление версиями major.minor.build.revision разрабатывает по сравнению с year.month.day.whatever стилем управления версиями
Если кто-нибудь сталкивался с этим, вот как я это сделал:
hcluster = clusGap(dataMatrix, FUN = hcut, nstart = 25, K.max = 100, B = 50)
k <- maxSE(hcluster$Tab[, "gap"], hcluster$Tab[, "SE.sim"], method="Tibs2001SEmax")
7 ответов
Преимущество времени состоит в том, что Вы получаете обоих увеличивающийся номер версии и кодируете метку времени.
Преимущество использования более традиционных чисел состоит в том, что для людей легче понять. Все мы знаем примерно, что "v2.1" означает, например.
В целом я предлагаю использовать время, потому что добавленная информация полезна. Преимущество других чисел для маркетинга только, и для которого можно сделать это так или иначе.
Например, почему бы не оба, а-ля "v2.1.20090214". Теперь у Вас есть маркетинг в разделе major.minor и утилита в разделе "сборки".
Я просто покидаю AssemblyVersion в "1.0.*" и удалите любой AssemblyFileVersion.
Я могу затем увеличить Номера основной версии и Номера вспомогательной версии, как кажется соответствующим, и позвольте DateTime по умолчанию основывать сборку и пересмотр быть автоматически установленными.
Если у Вас нет альтернативных инструментов сборки, управляющих сборкой, и число пересмотра согласно некоторой другой схеме I не видит реального преимущества для установки их вручную.
Используя время/дату имеет еще один (кроме уже упомянутых в других ответах здесь) недостаток:
если Вы - команда разработчиков, распространен по различным часовым поясам, Вы никогда не будете уверены, какую из двух версий создают на расстоянии в один час, более новый. Если Вы также не присваиваете версию часовому поясу или вынуждаете дату/время быть в, например, GMT.
Я использую некоторые сценарии сборки, которые обновляют мой пересмотр на основе пересмотра SVN. Это делает это тривиальным для отслеживания dll назад к исходному коду, который создал его.
Время более хитро; необходимо начать смотреть в области истории - тогда как большинство инструментов управления исходным кодом имеет, "получают пересмотр" средство.
Один недостаток основанной на дате нумерации версии является отрицательным восприятием старого программного обеспечения.
Хотя, я использую его так или иначе, потому что это соответствует моим проектам очень хорошо.
Почему выбирают? Можно использовать формат такой в качестве Главного. Незначительный. YYMMDD.Revision и получают лучший из обоих миров.
Редактирование, Как указано в комментариях иногда диапазон каждого поля ограничивается. В этом случае можно использовать Главный. Незначительный. YMMDD.Revision.
Надо надеяться, Вы изменяли бы вспомогательную версию по крайней мере каждые 10 лет!
Преимущество использования схемы major.minor.revision заключается в семантике. Существует метод обновления каждого из этих номеров:
Изменение основного номера означает, что новая версия несовместима со старой, и любой зависимой от предыдущей версии потребуется изменить код для обновления до нового пакета.
Незначительный номер изменение означает, что новая версия обратно совместима с предыдущей версией, но имеет значительные улучшения по сравнению с предыдущей версией.
Номер версии обновляется всякий раз, когда к сборке применяется исправление, так что это не вносит изменений совместимости или не вводит более новую features.
Таким образом, при указании зависимостей вы можете сказать, что вы зависите от foo-1.0.0 - foo-1.99.999, и будьте уверены, что обновление пакета не приведет к поломке вашего приложения.