Есть понятия:
— внутренний релиз
— внешний релиз
— билд

Как они друг с другом соотносятся (синонимы, часть-целое, разновидность)?
Как связаны их версии (синонимы, часть-целое, разновидность)?

еще есть
патч билд

Здравствуйте, igor-booch, Вы писали:

IB>Есть понятия:
IB>- внутренний релиз
IB>- внешний релиз
IB>- билд

IB>Как они друг с другом соотносятся (синонимы, часть-целое, разновидность)?
IB>Как связаны их версии (синонимы, часть-целое, разновидность)?
Это все зависит от системы, поставленной у вас. Имеется ввиду система, как процесс разработки, а не программа.

Мое ИМХО:
Внутренний релиз — это тестовый релиз, который должна тестировать группа тестирования
Внешний релиз — это релиз, который поставляются заказчику

А Билд и Патч-билд — это просто сборка общая (при релизе) и частичная (при внесении исправления).

Не знаю, может у кого-то другие будут объяснения.

То есть в процессе agile итерации мы делаем множество билдов, например с помощью continues integeration.

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

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

И теперь вопрос:

Чем отличается версия релиза, версия билда, версия программного продукта?

Я думаю вообще некорректно говорить версия релиза или версия билда. Тат как это подразумевает что у одного билда (или одного релиза) есть множество версий. Множество версий есть только у программного продукта. А версия программного продукта уже состоит из номера билда, номера внешнего релиза и номера внутреннего релиза. Правильно ли я рассуждаю ?

Здравствуйте, igor-booch, Вы писали:

IB>То есть в процессе agile итерации мы делаем множество билдов, например с помощью continues integeration.
IB>И билд, который мы отдали на тестирование в конце итерации, называется внутренним релизом.
IB>Если во внутреннем релизе обнаружились ошибки, и эти изменения тестеры хотят видеть до следующего внутреннего релиза выпускается патч билд внутреннего релиза.
IB>Внутренний релиз, который мы отдали заказчику, называется внешним релизом.
IB>Если во внешнем релизе обнаружились ошибки, и эти изменения заказчики хотят видеть до следующего внешнего релиза выпускается патч билд внешнего релиза.
Не работал по agile — извини, но интуитивно где-то так.

IB>И теперь вопрос:
IB>Чем отличается версия релиза, версия билда, версия программного продукта?
С моей точки зрения — это несколько разные вещи. Релиз — это новая версия ПО. В рамках релиза может быть несколько билдов, которые приближают релиз к идеалу. С патчем точно также. Есть патч (с енким именем, версией) и у этого патча могут быть итерации, на каждой из которых появляется свой билд.

N_C>С моей точки зрения — это несколько разные вещи. Релиз — это новая версия ПО. В рамках релиза может быть несколько билдов, которые приближают релиз к идеалу. С патчем точно также. Есть патч (с енким именем, версией) и у этого патча могут быть итерации, на каждой из которых появляется свой билд.

Согласен, я неправильно написал патч билд, нужно было написать патч релиз.

Здравствуйте, igor-booch, Вы писали:

IB>Чем отличается версия релиза, версия билда, версия программного продукта?

Они для разных людей делаются. Билд — уникальная попытка "получить действующее приложение". По сути, это сборка из исходников определенной версии. И версия исходников является "версией билда". Внутренний релиз — это определенный билд, отобранный на тестирование. Может иметь свою нумерацию (если тестировщикам это удобнее). Внутренний релиз может быть не выпущен (найдены ошибки, например) и будет создан новый билд и новый внутренний релиз. В конце концов тестирование будет завершено и продукт будет выпущен пользователям. Это будет внешний релиз. Этот внешний релиз получает отдельную версию, описывающую "пользователям" изменения. Т.е. релиз описывает набор изменений с точки зрения пользователя (бизнес-требования и т.п.). Естетственно, релиз соотносится с каким-то внутренним релизом (который утвердили). Внутренний релиз, в свою очередь, соотносится с билдом, из которого был получен. В обратную сторону цепочка не верна (для билда может не быть внутреннего релиза).

Чем отличается "версия релиза" от "версии программного продукта" в данном случае не понятно. Обычно они обозначают одно и то же. Второе используется при общении с пользователями (чтобы их не пугать), но обозначают они одно и то же. Иногда, "версия программного продукта" может обозначать группу "релизов". В этом случае "версия" обычно соотносится с major version в релизе.

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

Подробнее про патчи/релизы могу поредкомендовать статью Release Management Done Right. Она может показаться скучновата, но очень подробно описывает разницу между релизом и билдом.

Здравствуйте, igor-booch, Вы писали:

IB>Как они друг с другом соотносятся (синонимы, часть-целое, разновидность)?
IB>Как связаны их версии (синонимы, часть-целое, разновидность)?

Билд — это в буквальном переводе — "сборка". Т.е. берём срез исходников, создаём некие deliverables, т.е. исполняемые файлы, конфиги, скрипты SQL и т.п. Т.е. билд — полученные из исходников рабочие продукты. Создаётся как вручную по требованию, так и автоматическими системами сборок по расписанию. Как угодно, в общем — было бы что собирать.

Релиз — это билд, который команда разработчиков предоставляет наружу. В качестве потребителя релиза может быть как команда тестеров, так и пользователи. Соответствнно, внутренний релиз — это то, что отдаётся потребителю внутри компании (или команды), внешний релиз — соответственно, отдаётся наружу.

Как правило, релиз создаётся на основе т.н. baseline, т.е. базиса, базовой конфигурации. Команда, путём стабилизации свое работы, выбирает срез исхдников, который может быть использован или как основа для синхронизации всей команды (путём создания билда и его тестирования), или как основа для создания релиза (путём, опять же, создания билда, его тестирования и проверки соответствия критериям качества потребителя).

Пользуясь случаем, прорекламирую свою статью про основы SCM, где есть и про релизы, и про baselines: Основы SCM

Автор(ы): Юрий Удовиченко
Дата: 03.08.2009
В статье изложены основы Software Configuration Management (управления конфигурацией программных средств). Перечислены и описаны основные задачи, решаемые SCM, области его ответственности. Описано назначение стабилизации конфигураций и выделение базовых конфигураций. Даны примеры использования описанных принципов при компонентной разработке и с использованием линеек продуктов.

.