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


Все зависит от того, зачем вам нужна версия.
Что вы к ней хотите привязать ?
Функциональность ?
Документацию / инструкции пользователей ?
Сроки перехода со старой версии / планы ?

Нужно ли вам иметь возможность по номеру
версии идентифицировать значимость изменений в нем или нет ?

Номера релизов это пустая формальность, вопрос удобства.
Порядок в них нужен только вам, чтобы не запутаться
в том, что уже сделано, что будет сделано, что отгружено
заказчику.

Можно пойти простым путем: считать под номером релиза
порядковый номер операции отгрузки продукта заказчику (даже если
заказчик внутренний). То есть, если все готово, можно запускать в продакшен,
то версия 1.0.0 Изменения к этой версии (исправления) по порядку получают
приращение последней цифры. То есть, отгрузили заказчику версию
1.0.0 , потом в ней обнаружилась ошибка (бывает). Выпускаете исправленную версию
1.0.1. Если обнаружилась еще одна ошибка, то версия 1.0.2
Если потребовалось переделать функционал без исправления ошибки, то одна переделка
даст версию 1.1.0 Если после переделки функционала в нем ли или в старом функционале
обнаружилась ошибка, то выпускаете 1.1.1

Серьезное изменение архитектуры, внедрение новых подсистем
увеличивает первый номер. То есть, выпускаете 2.0.0

Как-то так.

oragrafaraman,

Лови классику

Он вообще не про это спрашивал.

Не про модель ветвления, а про подход к управлению релизами.

Одно из другого никак не следует. ;-)

И с каких это пор хипстерские заметки об очевидно стали классикой ?

Вот классика:
http://www.amazon.com/dp/0321685865

oragrafaddyy,

Судя по вопросу ТС, ему будет полезно много чего почитать. Твоя книга хорошая, спасибо, тоже почитаю.

да, пожалуйста ;-)

Читать надо всё, знания - сила !