2

Допустим, используется такой шаблон: "МАЖОРНАЯ ВЕРСИЯ.МИНОРНАЯ ВЕРСИЯ.БИЛД.РЕВИЗИЯ". Один разраб приступил к разработке одной фичи, таким образом, у него появилася ветка (к примеру) 1.1.0.1231, второй разраб приступил к разработке другой фичи, в результате появилась ветка 1.2.0.2345. Т.е. полагаем, что каждый инкремент минорной версии означает появление новой фичи, правильно? Тогда как называть интеграционную ветку? 1.2? 1.3? Или я вообще не по той логике думаю?

Nick Volynkin
  • 34,094
AndreyTalanin
  • 1,209

1 Answers1

2

На пректе, на котором я сейчас работаю (достаточно крупный, постоянно присутствуют несколько веток-фич, параллельных основной ветке), используется следующая методология: есть ветка develop, в которую разработчики мерджат свои ветки-фичи. Билды выпускаются только из неё. Если параллельно разрабатывается несколько версий продукта, то для каждой версии заводимтся своя develop-ветка, в которую мерджатся ветки-фичи данной версии.

fori1ton
  • 23,403
  • а как вы тогда в версии продукта обозначаете, что такая-то фича там есть? – AndreyTalanin Dec 03 '13 at 11:30
  • В чейнджлоге, само собой. Обычно подразумевается, что каждая следующая версия продукта включает в себя все фичи предыдущей. Если же какая-то фича была удаленаа - тоже пишем об этом в чейнджлог.

    У меня к вам встречный вопрос: а как вы тестируете свою программу? Выпускаете два билда с разными фичами и тестируете по отдельности? А затем мерджите ветки-фичи и снова тестируете, не поломал ли чего мердж? По-моему, это неэффективно. Частый мердж позволяет на ранней стадии выявить конфликты между фичами и устранить их в зародыше.

     – fori1ton Dec 03 '13 at 11:38
  • Где сейчас работаю, там другая методология. От заказчика поступают требования - мы (т.е. PM) их делим в соответствии с затратами времени и поровну в каждый будущий по календарю релиз впихиваем. Номера билдов и ревизий у нас не используются. Если цикл разработки необходимо прервать (заказчика приспичило, чтобы в следующем релизе была какая-нибудь фича), то создается промежуточная версия, и эту промежуточную версию мы обозначаем вместо билда, т.е. 5.0.1, 5.0.3 и т.д. Изнутри все еще проще - ветка-фича называется не версией, а по id требований, например master-40876 и т.д., интеграционная - 5.1 – AndreyTalanin Dec 03 '13 at 11:52
  • все верно, версии к ревизиям и веткам отношения не имеют. и вообще билд (третье число) имеет свой независимый инкремент (сквозь все минорные версии), а минорная версия инкрементится если добавлена фича. например: 
    1.0.1
1.0.5
1.1.6
1.1.89
1.2.90

    и т.д. в cvs релизные ревизии помечают tag'ом просто.

     – Yura Ivanov Dec 03 '13 at 11:54
  • Просто стало интересно, как у буржуев, и вообщем-то наткнулся на такой шаблон: http://programmers.stackexchange.com/questions/24987/what-exactly-is-the-build-number-in-major-minor-buildnumber-revision

    и вот сижу додумываю как бы это смотрелось у нас...

     – AndreyTalanin Dec 03 '13 at 11:57

  • билд (третье число) имеет свой независимый инкремент (сквозь все минорные версии)

    насколько мне известно, билд - это каждая логическая итерация в работе над фичей, и в принципе, нельзя сказать, что он независим от минорной версии или я не прав?

     – AndreyTalanin Dec 03 '13 at 12:06
  • 3
    бид генерится билд машиной, которой все равно какая минорная или мажорная версия. инкремент идет конкретной цифры - номера билда. сгенеренный билд передается в отк. это упрощает багтрэкинг. ошибка привязывается к номеру билда, в билд попадает список ревизий, таким образом проще отслеживать исправление багов, регрессии. если билд привязать к номеру минорной версии (фиче), то разобраться что же оттестили будет довольно сложно. – Yura Ivanov Dec 03 '13 at 12:18