Как семантическое управление версиями вписывается в рабочий процесс git

В настоящее время у меня проблемы с использованием семантического управления версиями. с git.

Мы используем модель управления версиями git по адресу http://nvie.com/posts/a-successful-git-branching-model/

Мы также хотели бы следовать рекомендациям по семантическому управлению версиями, изложенным по адресу http://semver.org/

Вот пример использования для нас.

Release branch: ----1----2----3----4 <- tag v1.2        ----7---8---9 <- tag v1.3
                   /                \                  /             \
Develop branch: --0--------5---------4--6-----------------------------9--

Вот наш пример использования:

• Разработка происходит параллельно при выпуске и разработке
• Выпуск готов к работе, мы помечаем его как v1.2. Мы создаем примечания к выпуску для изменений 1, 2, 3, 4.
• Мы объединяем выпуск обратно в разработку.
• Когда мы будем готовы снова перейти к разработке для другого выпуска, мы сможем это сделать. Однако тег v1.2 указывает на 4, поэтому примечания к выпуску для 5 фактически теряются, если мы запрашиваем изменения между версиями 1.2 и 1.3.

Мы хотели бы иметь возможность искать все новые проверки, добавленные с момента создания тега v1.2, которые были недавно включены в тег v1.3, чтобы мы могли определить, какой тип версии (xyz) для нашего компонента нам нужно сделать.

Если 5 оказалось значительным изменением, а все, начиная с версии 1.2 и далее, таковым не является, мы ошибочно поднимем второстепенную версию, поскольку проверка 5 не была включена в сборку.

Кто-нибудь может предложить, как это можно решить?