Когда вы меняете свой основной / младший / номер версии патча?

Возможный дубликат:
какое «соглашение об именах версий» вы используете?

Измените ли вы номера основных / второстепенных / патчей прямо перед выпуском или сразу после?

Пример: вы только что выпустили 1.0.0 для мира (хазз!). Но подождите, не празднуйте слишком много. 1.1.0 выходит через шесть недель! Таким образом, вы исправляете ошибку и делаете новую сборку. Как называется эта сборка? 1.1.0.0 или 1.0.0.xxxy (где xxxy - это увеличенный номер сборки 1.0.0)?

Имейте в виду, что вы можете иметь 100 функций и ошибок, чтобы перейти на 1.1.0. Так что было бы неплохо назвать его 1.0.0.xxxy, потому что вы не близки к 1.1.0. Но с другой стороны, другой разработчик может работать на 2.0.0, и в этом случае ваша сборка может быть лучше названа 1.1.0.0 и его 2.0.0.0 вместо 1.0.0.xxxy и 1.0.0.xxxz, соответственно.

После выпуска программного обеспечения номер версии должен быть немедленно увеличен.

Зачем?

Предположим, вы следуете схеме, подобной семантическому версионированию , и у вас есть номер сборки в версии. Таким образом, вы можете иметь [Major]. [Minor]. [Patch]. [Build]. Я собираюсь назвать [Major]. [Minor]. [Patch] часть версией.

Вы будете создавать несколько сборок во время разработки. Каждая сборка представляет собой снимок разработки вашего следующего выпуска. Имеет смысл использовать одну и ту же версию для разработки и выпуска сборки. Версии указывает на то , что релиз вы работаете в сторону .

Если вы готовитесь к выпуску, и программное обеспечение проходит все свои тесты, вам не нужно будет перестраивать и повторно тестировать программное обеспечение только потому, что вам пришлось обновить версию. Когда вы в конечном итоге делаете релиз, вы заявляете, что «build 1.1.0.23» отныне будет называться «версия 1.1.0».

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

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

Во время разработки я стараюсь сразу менять номера версий (если это возможно) . Иногда трудно понять, будет ли это изменение критическим или нет (что повлияет на мой номер версии), поэтому ничто не «в камне».

Чтобы обратиться к вашему конкретному примеру:

• Во время разработки предварительные версии будут 1.0.1-alpha.1, 1.0.1-alpha.2 и т. Д.
• Финальным выпуском исправления будет версия 1.0.1.

Сказав это, «общедоступные» номера версий продукта часто устанавливаются маркетингом и совершенно разные. Это вне моего контроля, так что не стоит беспокоиться об этом.

Давайте предположим ABCD в ответах. Когда вы увеличиваете каждый из компонентов?

Это в основном определяется политикой вашей компании. Политика нашей компании:

• A - Значительные (> 25%) изменения или дополнения в функциональности или интерфейсе.
• Б - небольшие изменения или дополнения в функциональности или интерфейсе.
• C - незначительные изменения, которые нарушают интерфейс.
• D - исправления в сборке, которые не меняют интерфейс.

В более крупных проектах / организациях номера старших и младших версий контролируются отделами маркетинга и обычно увеличиваются по маркетинговым причинам. В моей организации группы стремятся выпускать один основной и один дополнительный выпуск каждый год. Ожидается, что основные выпуски содержат значительную новую функциональность, и существует бинарная совместимость между API для всех выпусков с одинаковым номером основной версии. Тем не менее, маркетинг может принять решение понизить существенное изменение версии до незначительного, потому что обещанные функции не реализованы, или наоборот, как было замечено, чтобы перепрыгнуть через конкуренцию лягушки.

Основные и второстепенные номера сборки (c и d в abcd) обычно контролируются разработкой. c - номер сборки, а d используется для исправлений в конкретной версии или версии c.

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

Мы стараемся следовать примеру Eclipse . Это лучше объясняет, чем я, но эффективно для нас это работает так:

Когда вы выпускаете 1.0.0.0, номер версии, на которую вы меняете, зависит от типа изменений, которые вы делаете.

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

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

Следующей сборки нет. На этой ветке.

Идеализированный вариант нашей схемы.

Идентификацией версии в любой ветви является PRETTY_BRANCH_NAME-build, а PRETTY_BRANCH_NAME фиксируется при создании ветви.

Наша схема ветвления (*) следующая:

Ветви верхнего уровня, PRETTY_BRANCH_NAME каждого является кодовым именем, говорить о номере версии на этом уровне не имеет смысла, может быть запланированная схема, но она изменится до выпуска.

• TNG ( следующее поколение ) филиал, где осуществляется долгосрочное развитие. Часто у нас даже нет этого, и у него никогда не было (выпуска) подветвлений.

• ветвь TCG ( текущего поколения ), в которой ведется текущая разработка. PRETTY_BRANCH_NAME - это кодовое имя.

• ветвь TPG ( предыдущего поколения ). Часто здесь больше не ведется разработка, но может быть активность в подотраслях.

Подотрасль состоит из ветви верхнего уровня (TCG, в присутствии медленной миграции TPG), когда бета для основного релиза запускается. PRETTY_BRANCH_NAME - это что-то вроде «1.3.X» (X - это буква, а не цифра, это означает, что мы собираемся выпустить 1,3 релиза отсюда), обратная связь с бета-версией учитывается здесь, в то время как работа над следующим основным выпуском выполняется филиал TCG.

В идеале релиз должен быть моментальным снимком в этой ветке, но мы знаем, что мы не идеальны и часто должны вносить изменения в последнюю минуту, позволяя другим продолжить работу для следующего вспомогательного выпуска. Таким образом, подподразделения сделаны для окончательной стабилизации с красивыми именами, которые являются официальным номером версии (в то время даже маркетинг не захочет его менять), например, «1.3», «1.3.1» из ветви «1.3.X», последняя сборка каждого релиза.

Если бы у нас был четвертый уровень, имена подотраслей были бы «1.3.0.X», из которых у нас были бы под ^ 3branches «1.3.0.0» «1.3.0.1».

(*) На уровне релиза. На каждом из них могут быть ветки проекта.

Если вы продаете программное обеспечение, вы будете выпускать новый основной выпуск каждый раз, когда отдел продаж / маркетинга должен заработать больший бонус :-).

Если у вас есть контроль, то:

1. Основные релизы, когда:

   • Существует некоторая несовместимость с предыдущей версией, которая требует преобразования и т. Д., Например, из Python 2 в Python 3.

   • Существует целый кусок новой функциональности.

2. Незначительные релизы для любых небольших изменений в функциональности.

3. Выпуск патча для исправления ошибок.