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

Я согласен, что это довольно запутанно и не очень хорошо задокументировано. Это мое понимание:

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

В серии у вас есть вехи. Кажется, вы можете установить только одну веху за раз - вам нужно отпустить первую веху, чтобы установить вторую. Вехи, вероятно, будут вашими номерами версий, например. 0,1, 0,2.

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

Основные моменты к этому:

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

(извините за круговое определение здесь, но вот как оно работает).

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

Я вижу в основном два способа разработки проекта на Launchpad:

1. Разработка вашего проекта нелинейная (не уверен, что это правильное слово) , Как правило, это верно, если для вас важно поддерживать более одной версии одновременно при разработке в нестабильной ветке / разработке. (Подумайте о разработке двух версий параллельно)

   Например, GNOME имеет версии x.y.z с нечетным y, подразумевающим серию разработки, и четным y, подразумевающим стабильный ряд. GNOME выпускает 2.30 как стабильный для использования в мире. После релиза разработчики начинают работать над 2.31.x, который нестабилен. Если они находят какую-либо важную ошибку, которую они хотели бы исправить для пользователей, выполняющих 2.30 без предоставления огромного количества новых неполированных функций, они исправляют эту ошибку в 2.30 и выпускают 2.30.1. Если вы знакомы с bzr, вы должны понимать это с точки зрения того, что 2.31 разрабатывается на стволе, тогда как 2.30 является ветвью ствола (разветвленная, когда 2.29 стала стабильной и была выпущена как 2.30. ]) где делаются только исправления ошибок.

   В этом случае вы должны сделать одну серию для каждой 2.29, 2.30, 2.31 и т. Д. И одну trunk серию. 2.29 и 2.30 будут иметь одну и ту же ветку bzr (поскольку 2.30 - это 2.29 после полировки). 2.31 и trunk будут иметь одну и ту же ветку bzr. Когда вы освобождаете 2.32, ветвь ствола и вызывает эту ветвь 2.32 (это будет ветвь bzr для серий 2.31 и 2.32).

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

2. Разработка вашего проекта линейная . Это означает, что вы выпустите версию 1.1, которую будут использовать все, продолжайте разрабатывать функции и исправлять ошибки до тех пор, пока вы не будете готовы к 1.2 или 2.0 (или как хотите). Затем вы выпускаете последний доступный код. В этом случае вы не разрабатываете разные версии параллельно, как показано на диаграмме серий на Launchpad).

   В этом случае у вас есть только одна серия, одна базарная ветвь (предположительно обе trunk), и все ваши вехи и выпуски находятся в этой одной серии (будь то 0.1, 1.0, 1.1 или [ 1139])

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