Правильный способ использования версий и этапов

Ответ 1

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

Некоторые проекты имеют сопоставление 1:1 между версиями и вехами. Например, сам проект Trac имеет веху для выпусков 0.12.3, 0.13, 0.14 и т.д. Они также имеют более абстрактные вехи, которые не привязаны к определенному выпуску, например "next-major-0.1X" (который указывает, каков будет следующий крупный релиз), "неприменимо" и "незапланированный". Однако, когда вы идете создать билет, единственное, что указано в поле "Версия", - это выпуски версий и версий в активной разработке.

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

Ответ 2

Рабочий процесс выглядит примерно так:

• У вас есть билеты, которые могут быть запросами на новые функции, исправления ошибок, улучшения и т.д.
• Затем вы определяете, какие билеты имеют более высокий приоритет (в зависимости от того, что нужно пользователям или насколько критичным является исправление ошибок и т.д.).
• Чтобы организовать работу (и вовлеченные разработчики), вы можете указать что-то вроде "веха будет 2 недели" (может быть больше, может быть меньше, это зависит от вас)
• Затем вы можете оценить, сколько из этих билетов может быть фактически разрешено за такой промежуток времени (1 этап).
• Затем вы можете выпустить новую версию каждые несколько этапов (т.е. публичный релиз после 1 или 2-4 этапов, если только не нужно что-то критическое).

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

Ответ 3

Версии обычно больше для релизов для пользователей.

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

Там хорошее обсуждение этого здесь.