Блог

В этом вопросе немного смешивается управление проектами, а также разработка. Я понимаю [основное].[незначительный].[исправление] схема нумерации версий проекта. В проектах моих клиентов я использую эту нумерацию в основном для внутренних целей, поэтому вместо того, чтобы ссылаться на проект по задействованным функциям, команда может сказать «каков прогресс версии v1.3.2?».

Однако иногда у наших клиентов есть несколько второстепенных выпусков одновременно. Каждый второстепенный выпуск содержит набор независимых функций (работающих с разными отделами компании-клиента), но оба могут запускаться в разное время. Итак, если мы обозначим их как версии v1.3.3 и v1.3.4, версия v1.3.4 может быть выпущена раньше, чем версия v1.3.3, и тогда вся схема именования недействительна.

Как вы ссылаетесь внутренне на эти различные сборки, если вы не знаете, какая из них будет выпущена первой (из-за ожидания одобрения клиентом или других внешних конфликтов планирования)?

Спасибо!

Довольно просто — мы не присваиваем номера версий до тех пор, пока не выпустим. Проблема решена!

Это может показаться легкомысленным, но это правда. Конечно, у нас были бы внутренние проекты, получившие название, например, «v5.5», но они были бы отдельными и независимыми от текущей работы над следующей итерацией v5.4.x, которая получила бы следующее значение ‘x’ только после завершения и выпуска. Когда версия 5.5 готова, работа над 5.4 прекращается, мы объединяем все изменения, внесенные в 5.4, в 5.5, а затем выпускаем 5.5.0.

Если у вас есть отдельные сборки для разных клиентов (в вашем случае отделов), вы можете использовать модифицированную схему управления версиями. То, что мы сделали, это использовали [major].[незначительный].[клиент].[исправление], например 5.4.client1.4. [Исправление] было бы независимым и значимым только для этого конкретного клиента, тогда как [основной].[второстепенный] будет соответствовать [главному].[второстепенная] версия основной кодовой базы, от которой мы отклонились. Например, у нас может быть одновременная работа над 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] и [patch], чтобы было ясно, что, например, 5.4.7 может на самом деле содержать больше исправлений / быть более «актуальным», чем 5.4.12.client1, и лучше сообщать об этой независимости.

Когда проект, зависящий от конкретного клиента, объединяется обратно, вы, конечно, отбрасываете его и переходите к следующему [исправлению] или, возможно, переходите к следующей [второстепенной] или даже [основной] версии, в зависимости от характера работы. Иногда это приводит к некоторой временной путанице, когда клиентский проект объединяется с проектом 5.4.x, а затем мы выпускаем с этой версии 6.0, затем не забываем переименовать внутренний проект 5.5 в 6.1, но, тем не менее, это сработало.

В качестве альтернативы для вашей среды, внутренне ссылайтесь на свои текущие проекты просто по названию клиента (отдела), например, проект бухгалтерского учета, проект управления персоналом и т.д. Не используйте номера версий внутренне для такого рода вещей, потому что, как вы видите, это просто приводит к путанице, например, версия 5.4.6 выходит после 5.4.7, но до 5.4.9; между тем 5.4.8 никогда не будет выпущена, потому что она была отменена. Это просто беспорядок, так что держитесь от этого подальше. Просто называйте свои проекты по имени клиента и присваивайте следующий номер