Довольно просто - мы не назначаем номера версий, пока не выпустим.Проблема решена!
Может показаться легкомысленным, но это правда.Конечно, у нас были бы внутренние проекты, озвученные, например, «v5.5», но они были отдельными и независимыми от текущей работы над следующей итерацией v5.4.x, которая получала бы следующее значение «x» только после завершения и выпуска,Когда v5.5 готов, работа над 5.4 прекращается, мы объединяем любые изменения, внесенные в 5.4, в 5.5, а затем выпускаем 5.5.0.
Если у вас есть отдельные сборки для разных клиентов (отделы в вашем случае)Вы можете использовать модифицированную схему управления версиями.Мы использовали [major]. [Minor]. [Client]. [Patch], например 5.4.client1.4.[Patch] будет независимым и значимым только для этого конкретного клиента, тогда как [major]. [Minor] будет соответствовать [major]. [Minor] версии основной кодовой базы, из которой мы вышли.Например, у нас может быть одновременная работа над 5.5, 5.4.x и 5.4.client1.x.Когда 5.5 готов, 5.4.x объединяется с этим, и затем оба проекта складываются в 5.5.x, но клиентский проект может быть не готов объединить все эти изменения, и, таким образом, он останется 5.4.client1.x до тех пор, пока не будет запущен- на сегодняшний день с 5.5, затем ставшим 5.5.client1.x.
Это может показаться странным, но на самом деле это очень хорошо сработало для нас.Ранее мы использовали вариант этой схемы, где имя клиента добавлялось к полному номеру версии, то есть [major]. [Minor]. [Patch] _ [client];опять же, однако, [major]. [minor] соответствует «ядру» [major]. [несовершеннолетнему], откуда оно было разветвлено / последний объединено, и [патч] полностью независим от других версий и имеет значение только для этогоclient (именно поэтому мы позже поменялись местами взаимного расположения [client] и [patch], чтобы было ясно, что, например, 5.4.7 может иметь больше исправлений / быть более «текущим», чем 5.4.12.client1, и лучшепередать эту независимость.
Когда клиентский проект сливается обратно, вы, конечно, отбрасываете его и увеличиваете до следующего [патча], или, возможно, делаете переход к следующему [второстепенному] или даже [мажорному], в зависимости от характера работы, что иногда приводит к некоторой временной путанице, когда клиентский проект сливается с проектом 5.4.x, а затем мы выпускаем эту версию 6.0, а затем переименовываем внутренний проект 5.5 в 6.1,но, тем не менее, это сработало.
В качестве альтернативы для вашей среды, внутренне обратитесь к своим текущим проектам просто поимя ent (отдела), например, учетный проект, HR-проект и т. д. Не используйте номера версий внутри себя для такого рода вещей, потому что, как вы видите, это просто приводит к путанице, как версия 5.4.6, выходящая после 5.4.7но до 5.4.9;Между тем 5.4.8 никогда не выпускается, потому что он был отменен.Это просто беспорядок, так что держись подальше от этого.Просто назовите свои проекты по имени клиента и назначьте следующий номер