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

В настоящее время мы используем следующую схему нумерации версий для нашего проекта winforms C #:

«Основной выпуск». «Незначительный выпуск». «Номер итерации». «Номер сборки в этой итерации»

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

Раньше мы делали что-то вроде: «Основной выпуск». «Незначительный выпуск». «Последовательный номер сборки от 1.0». Например, «4.0.648» будет означать, что с 1.0 было 648 сборок, но эта информация бесполезна и анекдотична, поэтому мы изменили ее, чтобы отразить итерации и сборки внутри итераций.

Итак, учитывая эту новую нумерацию гибкой версии, у нас теперь есть проблема, когда другая группа продуктов хотела бы внести изменения в свою итерацию для нашего проекта. В этом случае номер версии не имеет смысла, потому что их номера итерации и сборки не соответствуют. Например, последняя сборка моего проекта была 1.0.5.1, что указывает на 1-ю сборку итерации 5. Теперь этот другой проект, который находится на 3-й итерации, хотел бы внести изменения в мой проект и перестроить.

Как мне справиться с этой ситуацией? Как вы выполняете нумерацию версий в своем гибком проекте?


c# agile versioning
person Paul Fedory    schedule 27.01.2009    source источник
comment
У Agile-разработчиков нет номеров версий. Это попахивает документацией.   -  person cletus    schedule 27.01.2009
comment
как они будут отслеживать выпуски по номеру версии?   -  person simgineer    schedule 15.12.2011

Ответы (4)


arrow_upward
5
arrow_downward

Я отслеживаю итерацию гибких проектов, а не итерацию программных проектов. Если сторонний проект с поздним запуском присоединяется после другого проекта, он, следовательно, запускается с текущей итерацией гибкого проекта, и несоответствия не будет.

Технический проект за пределами области гибкого проекта не должен иметь возможности взаимодействовать с проектом в этой области. Это было бы ошибкой PM процесса и должно быть устранено во всех случаях, когда общая база кода используется с ветвлением, чтобы быть исправленным в магистрали в качестве этапа очистки после завершения проекта.

person annakata    schedule 27.01.2009
comment
Красиво, ясно и по делу. +1 - person EricSchaefer; 27.01.2009

arrow_upward
5
arrow_downward

Лично я считаю, что управление версиями релизов, которое мне больше всего понравилось, - это полное избавление от всего major.minor. Я думаю, что это реально возможно только для внутренних приложений, но в этом случае это значительно упрощает жизнь.

Обычно, если вы разрабатываете внутренние приложения, я заметил, что бизнес никогда не заботится о том, какую основную / вспомогательную версию они используют. Вместо этого они, как правило, хотят знать: а) когда выйдет следующий релиз и б) что будет, а что выйдет - вот и все. Попытки сохранить тот факт, что вы работаете над FOO-4.34.0.1-a и BAR-3.19.4.1, когда всем плевать, только усложняют общение.

В предыдущей группе у нас действительно не было крупных релизов, кроме начала проекта. Каждый выпуск был таким же «мажорным», как и предыдущий.

В результате, я думаю, они поступили разумно и вместо этого обратились к бизнесу как PROJECT_RELEASENUM. Номер выпуска увеличивался на «1» каждый раз, когда мы делали выпуск, с патчами как PROJECT_RELEASENUM_PATCHNUM, который также увеличивался на «1».

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

person awied    schedule 12.11.2009

arrow_upward
3
arrow_downward

Я предпочитаю Major.Minor.Build.Revision, где Build - количество публичных релизов, Revision - ревизия из исходной системы версий.

person abatishchev    schedule 27.01.2009

arrow_upward
2
arrow_downward

Я предпочитаю отделить процесс сборки и выпуска от процесса командной разработки, поэтому вряд ли добавлю итерацию, спринт или что-то подобное к версии. Ваш случай - прекрасный пример того, как нелегко совмещать обе вещи. Что, если вы измените методологию в середине проекта (какой бы ни была причина)?

Отвечая на ваш вопрос, мы используем Scrum в течение двух лет, и наш формат версии - классический Major.Minor.Upgrade.Build (мы используем Upgrade только для исправлений ошибок). В конце концов, не обязательно использовать номер сборки, так как он нужен вам только для устранения неоднозначности разных пакетов из одной и той же версии, но вы можете использовать другой символ, представляющий какую-то частную версию.

person t3mujin    schedule 27.01.2009