Отвечая на ваш вопрос, мы используем Scrum в течение двух лет, и наша версия формата является классической Major.Minor.Upgrade.Build (мы используем обновление только для исправлений). В конце концов, не обязательно использовать номер сборки, так как он нужен только для устранения неоднозначности разных пакетов из одной и той же версии, но вы можете использовать другой символ, который представляет какую-то частную версию.
тоящее время мы используем следующую схему нумерации версий для нашего проекта C # winforms:
"Major Release". "Minor Release". "Номер итерации". "Номер сборки в этой итерации"
Мы хотели иметь возможность идентифицировать номер итерации и номер сборки в этой итерации, просто взглянув на номер версии.
В прошлом мы делали что-то вроде: «Major Release». «Minor Release». «Sequential Build Number from 1.0». Например, «4.0.648» означало бы, что начиная с 1.0 было 648 сборок, но эта информация довольно бесполезна и случайна, поэтому мы изменили ее, чтобы отразить итерации и сборки внутри итераций.
Итак, учитывая новую гибкую нумерацию версий, у нас теперь есть проблема, когда другая группа продуктов хотела бы внести изменения в свою итерацию для нашего проекта. В этом случае номер версии не имеет смысла, потому что их номера итерации и сборки не соответствуют. Например, последняя сборка моего проекта была 1.0.5.1 с указанием 1-й сборки итерации 5. Теперь этот другой проект, который на 3-й итерации хотел бы внести изменения в мой проект и перестроить.
Как мне справиться с этой ситуацией? Как вы делаете нумерацию версий в своем гибком проекте?