Изменение версии кода "правила"

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

1) Как правильно обновить версии

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

Как я добавил больше функциональности, я обновлял младший номер. Теперь я в v0.5.7 (minor (.5) для новых функций и ревизий (.7) для исправлений ошибок и незначительных изменений), дело в том, что программа почти завершена для распространения, но теперь я "пропущен" "несколько второстепенных версий, как вы, ребята, справляетесь с этой ситуацией? просто перескакиваете цифры?

Это подводит меня ко второму вопросу.

2) Какой хороший стартовый номер версии

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

Бонусный вопрос:

3) Можно ли делать числа выше 10? как v1.25 или v2.2.30?

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

Ответ 1

Политики нумерации версий иногда могут быть немного сумасшедшими (см. Номера версий и JSR277 или Oracle с Oracle Database 11g Release 2: 11.2.0.1.0.
См. Также Управление версиями программного обеспечения - смешно).

Но вы можете начать, взглянув на политику "Номер версии Eclipse" как на хорошее начало.
Если вы действительно считаете, что вам нужно более трех цифр, это объяснение терминологии средства доставки потока обслуживания VRMF также интересно, но в большей степени это относится к программному обеспечению, выпущенному после 1.0, в котором исправлены пакеты исправлений и временные исправления.

1/"Отправь уже": 1.0.0

Также известна как 1.oh-oh " 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 (а Nth будет v1.9.N); а также

Релиз функции после v1.9.0 будет либо v1.10.0, либо v2.0.0, в зависимости от того, насколько большим будет скачок функции.

Ответ 2

В нашей компании мы используем концепцию управления четырьмя токенами. Это что-то вроде abcd вида:

(major).(feature).(revision).(bug/refactoring)

Это связано с типами проблем, которые мы используем в нашем жизненном цикле разработки. Мы можем отследить, что было сделано или изменено между двумя следующими версиями. Сравнивая два следующих номера версии, вы можете определить количество и типы решенных проблем. Для получения дополнительной информации полная документация здесь.

Ответ 3

Даже я столкнулся с этой проблемой при определении номера версии при разработке с помощью CRM, так как я хотел развернуть одну и ту же сборку во всех системах. Я нашел способ разрешить его с помощью System value + Manual + randoms.

Информация о версии для сборки состоит из четырех значений:

Основная версия. Незначительная версия. Номер сборки. Revision

По умолчанию исходная версия 1.0.0.0. Чтобы иметь больше смысла, я заменяю его на

Отпуск TFS. TFS Sprint. Изменить номер. Увеличенный номер сборки

Предположим, что в вашей TFS одна версия состоит из 30 спринтов, и после этого релиз становится равным 2, поэтому значения для первой версии будут:

Выпуск TFS: 1

Если текущий спринт равен 4, TFS Sprint будет иметь

TFS Sprint: 4

Теперь третья часть управляется разработчиком, для начальной версии мы можем иметь 0, который может быть увеличен на +1 для каждого ChangeRequest или BugFix.

Изменить номер: 0 - представить начальную версию Изменить номер: 1 - представить изменение Изменить Numbe 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 и с некоторым изменением кода.