В чем заключается полезная стратегия управления версиями веток?

Мы перешли к подходу к управлению версиями продукта, который будет отмечать / увеличивать сборки в соответствии со следующим форматом: [Major]. [Minor]. [Build]. [ Revision / Patch] , а производственный выпуск будет, по сути, увеличиваться на Major или Minor (в зависимости от объема изменений).

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

Независимо от того, объединимся ли мы до ствол (или нет), есть ли у кого-нибудь полезные стратегии для работы с версиями ветки нг? Нам нужно будет иметь возможность однозначно идентифицировать сборки из веток и ствола, и мы можем закончить выпуск из ствола или веток в любой момент времени.

Некоторые соображения:

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

Может помочь (облегченный) сценарий:

Product X\Trunk (ver 1.1.208.0)
Product X\Branches\Feature A (ver 1.1.239.0)
Product X\Branches\Feature B (ver 1.1.221.0)

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