Изменение кода версии "правила"
Я знаю, что нет определенных правил контроля версий программного обеспечения, но у меня есть несколько вопросов.
1) Как правильно обновлять версии
У меня есть небольшое программное обеспечение, которое я запустил некоторое время назад, и так как я начал с нуля, я начал с версии 0.1.
Поскольку я добавил больше функциональности, я обновлял младший номер. Сейчас я нахожусь в v0.5.7 (второстепенный (.5) для новых функций и ревизии (.7) для исправления ошибок и незначительных изменений), дело в том, что программа почти готова к распространению, но сейчас я "отсутствует" "Несколько минорных версий, как вы, ребята, справляетесь с такой ситуацией? ты просто прыгаешь числа?
Это подводит меня ко второму вопросу.
2) Какой хороший начальный номер версии
Я собираюсь начать новый проект. На этот раз это не маленький проект, и он будет общедоступным и бесплатным для модификации, я не хочу иметь проблемы, упомянутые выше. Так что будет хорошей отправной точкой?
Бонусный вопрос:
3) Можно ли делать числа выше 10? как v1.25 или v2.2.30?
Я не видел программного обеспечения с такой нумерацией (вероятно, они показывают его только в разделе справки или на своей веб-странице), опять же, я знаю, что для этого нет никаких правил, но, похоже, что есть общие согласие о том, как сохранить номера версий.
4 ответа
Временами политики нумерации версий могут быть немного сумасшедшими (см. Номера версий и JSR277 или Oracle с Oracle Database 11g Release 2: 11.2.0.1.0,
См. Также Управление версиями ПО - это смешно).
Но вы можете начать, взглянув на политику "Номер версии Eclipse" как на хорошее начало.
Если вы действительно считаете, что вам нужно более трех цифр, это объяснение терминологии средства доставки потока обслуживания VRMF также интересно, но в большей степени это относится к программному обеспечению, выпущенному после 1.0, в котором исправлены пакеты исправлений и временные исправления.
1 / "Отправь уже": 1.0.0
Также известный как 1.oh-oh версия. По крайней мере, она есть, и вы можете начать получать отзывы и быстро выполнять итерации.
2 / 0.x если основные функции все еще отсутствуют; 1.0.0 если основные функции есть.
3 / Да, но я бы сказал, что только для крупных проектов со сроком службы более нескольких лет (обычно десятилетие)
Обратите внимание, что "правильно" (хотя и подробно описано в Semantic Versioning 2.0.0) также может руководствоваться более прагматическими факторами:
Смотрите объявление о Git 1.9 (январь 2014):
Кандидат на выпуск Git v1.9-rc2 теперь доступен для тестирования в обычных местах.
До меня дошли слухи о том, что различным сторонним инструментам не нравятся двузначные номера версий (например, "Git 2.0"), и я начал бить влево и вправо, когда пользователи устанавливают v1.9-rc1.
Хотя соблазнительно смеяться над ними из-за их небрежного предположения, я также практичен и не против позвонить в предстоящий выпуск v1.9.0, чтобы помочь им.Если мы пойдем по этому маршруту (и я склонен идти по этому маршруту в данный момент), схема управления версиями будет такой:
- Следующий релиз-кандидат будет
v1.9.0-rc3неv1.9-rc3;- Первый технический релиз для
v1.9.0будетv1.9.1(и N-й один будетv1.9.N); а также- Релиз функции после v1.9.0 будет либо v1.10.0, либо v2.0.0, в зависимости от того, насколько большим будет скачок функции.
Обновление: февраль 2019 года: сам semver собирается развиваться (снова после semver2).
Смотрите " Что дальше для SemVer ", и semver/semver/CONTRIBUTING,
В нашей компании мы используем концепцию управления четырьмя токенами. Это что-то вроде abcd вида:
(major).(feature).(revision).(bug/refactoring)
Это связано с типами проблем, которые мы используем в нашем жизненном цикле разработки. Мы можем отследить, что было сделано или изменено между двумя следующими версиями. Сравнивая два следующих номера версии, вы можете определить количество и типы решенных проблем. Для получения дополнительной информации полная документация здесь.
Даже я столкнулся с этой проблемой при определении номера версии при разработке с CRM, поскольку я хотел развернуть одну и ту же сборку во всех системах. Я нашел способ решить это с помощью System value + Manual + randoms.
Информация о версии для сборки состоит из четырех значений:
Основная версия. Малая версия. Номер сборки. пересмотр
Что делает исходную версию 1.0.0.0 по умолчанию. Чтобы иметь больше смысла, я заменяю его
TFS Release. TFS Sprint. Изменить номер. Увеличенный номер сборки
Предположим, что в вашем TFS один выпуск состоит из 30 спринтов, и после этого выпуск становится 2, поэтому значения для первого выпуска будут следующими:
TFS Release: 1
Если текущий спринт равен 4, спринт TFS будет иметь
TFS Sprint: 4
Теперь третья часть управляется разработчиком, для начальной версии у нас может быть 0, которое может быть увеличено +1 для каждого ChangeRequest или BugFix.
Номер изменения: 0 - представляет исходную версиюНомер изменения: 1 - представляет изменение Номеризменения r: 2 - представляет исправление
Хотя для каждого исправления может быть изменение в коде, поэтому оно представляет изменение кода по умолчанию. Но для большей ясности у вас может быть нечетное число, представляющее изменение, и четное число, представляющее исправление.
Последняя часть была номером по умолчанию, к счастью.Net позволяет нам поставить *, чтобы поставить номер сборки по умолчанию. Он продолжает увеличиваться с каждой компиляцией / сборкой, которая обеспечивает печать подписи, если кто-то другой перестраивает ее, изменения.
Как реализовать:
Откройте AssemblyInfo.cs в папке "Свойства" и закомментируйте AssemblyFileVersion, это сделает AssemblyFileVersion и AssemblyVersion одинаковыми.
// You can specify all the values or you can default the Build and Revision Numbers
// by using the '*' as shown below:
[assembly: AssemblyVersion("1.4.2.*")]
//[assembly: AssemblyFileVersion("1.0.0.0")]
Таким образом, окончательная версия выйдет как: 1.4.2.4512 или что-то
Преимущества этого подхода в том, что вы можете отслеживать задачу, для которой генерируется код. Просто взглянув на номер версии, я могу сказать: "Эй, это релиз 1 для спринта 4 и с некоторым изменением кода.
Семантическое управление версиями в значительной степени де-факто в наши дни.
Я "пропускаю" несколько минорных версий, как вы, ребята, справляетесь с этой ситуацией?
Вы не пропустите версии. Это вполне приемлемо для... (см. Следующий ответ)
Какой хороший начальный номер версии
Зависит от того, используют ли люди ваш код в производстве. Если он уже используется в производстве, перейдите прямо к v1.0.0, Но так как вы сказали, что ваш код имеет альфа, бета или rc (релиз-кандидат) качество, но вы планируете быстро перейти к производству, подумайте о начале v1.0.0-[alpha].N где [alpha] это класс программного обеспечения и N это номер сборки или другое перечисляемое значение.
Можно ли делать числа выше 10? как v1.25 или v2.2.30?
Это идея. Лексикографическая сортировка может не работать, но это нормально.