Как вы создаете версии своих проектов и управляете релизами?

Question

Наша ситуация выглядит следующим образом, но мне любопытно об этой проблеме в любой ситуации.

У нас есть фреймворк, состоящий из 4 проектов:

• бобы
• Util
• основа
• 1012 * Веб *

У нас также есть модули, которые нуждаются в версии и зависят от версии bean-компонентов и утилит.

Наконец, у нас есть проект заказчика, который состоит из определенной версии основных проектов и одного или нескольких модулей.

Есть ли стандартный способ создания версий этих проектов?

То, что мне кажется простым, становится действительно сложным, когда мы пытаемся доставлять релизы в QA, а затем управляем нашей текущей разработкой с помощью поддержки релиза (release = tag и возможная ветвь).

Я предпочитаю следующее:

1.2.0 - основная и дополнительная версии + выпуск.

1.2.1 - следующий выпуск

1.2.0_01 - исправление ошибки в версии 1.2.0 (ветка)

и т.д.

Есть идеи?

Answer 1

Мы используем major.minor.bugfix. Главный выпуск происходит только для огромных изменений. Незначительный выпуск вызывается при изменении API. Все остальные выпуски являются исправлениями ошибок. Там определенно полезна возможность иметь номер сборки или ревизии там также для устранения неполадок, хотя, если у вас действительно строгий CM, вам, возможно, не нужно его включать.

Координация между версиями всех этих проектов может быть действительно хорошо выполнена с помощью таких инструментов, как Apache Ivy или Maven. Сборка одного проекта с собственным номером версии может включать агрегацию определенных версий (продуктов) других проектов, поэтому ваши файлы сборки обеспечивают строгое сопоставление версий снизу вверх. Сохраните все это в [вставьте сюда любимый инструмент контроля версий], и у вас будет хорошая история.

Answer 2

Я использую {major}. {Minor}. {Buildday}. {Sequential}. Для Windows мы используем утилиты stampver.exe и UpdateVersion.exe для проектов .NET, которые обрабатывают это в основном автоматически.

Answer 3

Я использую вариант в системе нумерации версий ядра Linux:

major.minor.bugfix

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

Answer 4

В автоматизированной системе сборки я в настоящее время использую I версию с Major.Minor.Build.X, где Build - это каждый раз, когда мы выполняем проверку системы, а X - последний номер ревизии Subversion из репозитория, в котором строится код. от. Кажется, что это работает довольно хорошо для Subversion, поскольку мы можем легко вернуться к базе кода конкретной сборки, если возникнет такая необходимость.

Answer 5

Стандартных систем нумерации нет. Обычные темы должны иметь основной, вспомогательный номер и номер сборки, а иногда и номер точки (например, 1.2.2.1 для версии 1.2, выпуск 2, сборка 1). Значение номеров версий очень гибкое. Частым выбором является обратная совместимость между второстепенными или точечными выпусками.

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

Answer 6

Одним из наиболее распространенных соглашений является major.minor.bugfix, с дополнительным суффиксом, указывающим номер сборки или предварительный выпуск (например, альфа, бета и т.

Численность моей команды строится в соответствии с основными этапами проекта - сборка передается нашей группе контроля качества в конце итерации разработки (каждые несколько недель). Промежуточные сборки CI не нумеруются; поскольку мы используем Maven, эти сборки нумеруются с суффиксом SNAPSHOT.

Что бы вы ни решили, обязательно запишите это и убедитесь, что все это понимают. Я также предлагаю вам документировать и последовательно применять политику ветвления релизов, иначе она может быстро запутаться для всех. Хотя, имея всего 4 проекта, следить за происходящим должно быть довольно легко.

Answer 7

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

Как заявил workmad3, на самом деле нет единого правила для номеров сборок. Мой совет - использовать то, что имеет смысл для вашей команды / компании.

В некоторых местах, где я работал, нумерация сборок была приведена в соответствие с этапами и итерациями проекта,
Например: Major = Release или Milestone, Minor = Итерация, Build = Номер сборки (с начала проекта или с начала итерации), Revision = Если сборка должна быть перестроена (или разветвлена).

Answer 8

В настоящее время у нас нет реальных версий. Мы используем номер сборки svn и дату выпуска. (имя тега похоже на release_081010_microsoft, например.)

Старые продукты используют нумерацию версий major.minor.sub

Майор никогда не менялся Незначительные изменения в каждом выпуске / выпуске релиза каждые 6 месяцев. Sub - это все, что не влияет на набор функций - в основном исправления ошибок.

Answer 9

Вы не упомянули, имеет ли какой-либо проект доступ к базе данных, но если таковой имеется, это может быть другим фактором, который следует учитывать. Мы используем схему major.minor.bugfix.buildnumber, аналогичную схеме, описанной в ответах на этот вопрос, с примерно такой же логикой, но с дополнительным требованием, чтобы любые изменения схемы базы данных требовали хотя бы небольшого приращения. Это также обеспечивает схему именования для ваших схем базы данных. Например, версии 1.2.3 и 1.2.4 могут работать как со схемой базы данных «1.2», но для версии 1.3.0 требуется схема базы данных «1.3».