Какова хорошая стратегия ветвления при разработке нескольких будущих выпусков одновременно?

Question

Прошлое

Я разрабатываю программный проект, используя Subversion в качестве scm.До сих пор разработка всегда происходила в trunk, поэтому проблемы возникали, когда требовался выпуск исправлений.Теперь мы хотим переосмыслить нашу стратегию ветвления, и требование таково: мы хотим иметь возможность работать с несколькими будущими выпусками одновременно.

Задача

Это означает: Предположим, текущая версиямы работаем над 1.0.Следующая запланированная версия - 2.0, версия после этого - 3.0.Теперь, когда мы выпустили 1.0, мы хотим

• поддерживать версию 1.0
• , разрабатывать функции для 2.0
• , в то же время разрабатывать функции для 3.0
• Магистраль будет заброшена
• Для каждого нового запланированного выпуска создается ветвь, которая вытекает из ветви последнего выпуска
• Изменения распространяются "вверх"msgstr "на временной шкале версии

Позвольте мне уточнить это немного подробнее: в данном примере мы разветвляем версию 1.0 из транка.Кроме того, мы бы выпустили версию 2.0 с версии 1.0 и версию 3.0 с версии 2.0.Когда изменение сделано в 1.0, оно будет объединено в 2.0, а затем в 3.0.

Вопрос

Является ли это действительной методологией?Будет ли это работать технически?Есть ли организационные подводные камни?Есть ли лучшие практики?(Все, что может предложить интернет, это: «Разработка в транке, поддержка в ветке релиза»).Мне особенно странно отказываться от багажника - это неправильно?

Answer 1

Идея "разработки в trunk" основана на том факте, что trunk является веткой по умолчанию, которую вы можете оформить.
Т.е.: вы не имеете представления о соглашении об именах для других ветвей, но выпо крайней мере, знайте, что «основная» ветвь называется «trunk», поэтому, как новый разработчик, вы можете испытать желание проверить эту ветку, поэтому текущая разработка лучше всего выполняется в этой же ветке.

Ответвления 1.0, 1.1 или 2.0, скорее всего, предназначены для операций обслуживания после завершения этих выпусков.

Для параллельной разработки я бы порекомендовал другое соглашение об именах, например 1.1_dev, 2.0_dev, сделанный из trunk (который будет представлять текущую 1.0 разработку).
Это может работать, если эти ветви не слишком долговечны, и что они не слишком сильно расходятся сtrunk (из-за слияний, которые в противном случае становились бы все более сложными).