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

Это прекрасно работает для патчей и сборок Trunk, но не так хорошо для параллельной разработки функций в ветвях - тем более, что, скорее всего, мы будем строить кандидатов на выпуск из ветки вместо слияния с 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 хотя это немного расплывчато в уникальных версиях параллельных ветвей.