Работа с номерами версий программы

    А на моей машине все работает!
    Из ненормативной лексики программистов.


    Для того, чтобы программисты, тестировщики и пользователи программы могли понимать где и что происходит, где произошла ошибка или когда можно посмотреть на новую фичу, применяют версии программы. Самый простой способ — это одно число, увеличивающееся на единицу каждую сборку. Иногда этот метод наилучший. А что в других продуктах?


    У моего IE номер версии 8.0.6001.18828, а у Paint версия 6.0, но номер сборки 6002.
    Для обозначения номеров версий продуктов Microsoft Office используется следующий синтаксис:
    aa.bbbb.cccc
    * aa: Версия Office.
    * bbbb: Версия исполняемого файла программы, например Excel.exe.
    * cccc: Версия файла Mso.dll.

    Но оригинальнее всего поступил Дональд Кнут. С версии 3.0 TeX использует характерную систему нумерации версий: каждое обновление добавляет дополнительную десятичную цифру к номеру версии, так что она асимптотически приближается к π. Это отражает тот факт, что текущая версия TeX'а — 3.1415926 — очень стабильна и возможны лишь мелкие обновления (см. ru.wikipedia.org/wiki/TeX).

    Забудем пока о шутке Кнута. Как все-таки удобнее? В своем семинаре по настройке бактрекера я рассказываю про различные группы атрибутов. Есть атрибуты описательные, а есть управляющие.

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

    А вот для управления фичами и дефектами удобно использовать номер официального релиза. Пусть мы набираем задачи для четырехнедельной итерации. Сейчас вышел релиз 2.14, следующий будет 2.16. То что, мы передаем в эксплуатацию должно иметь метку. Иначе конечному пользователю будет очень тяжело общаться с нами. Иногда удобно делать структуру большое изменение/малое изменение. Например, «версия 2» была на php+MySQL, а версия 3 будет на .Net+MSSQL. В четвертой же версии мы перейдем с трехуровневой на четырехуровневую архитектура и наконец сделаем толстый клиент. А в версии 5 наконец сделаем логистику в дополнение к складскому учету. Т.е. версии 2.х, 3.х, 4, х – это большие прыжки, а переход 3.12-3.14 это выпуск патчей, добавление небольшой функциональности и т.д.

    Иногда делают и три уровня:
    • первый уровень – большие прыжки, раз в 6-30 месяцев
    • второй уровень – малые прыжки, раз в 2-4 недели
    • третий уровень – срочные патчи по требованию в любое время

    При этом вполне может наблюдаться картина, когда часть команды работает над версией 4.0, другая готовит 3.14, и пара ребят с быстрыми руками готовят 3.12.1 и 3.12.2 (номер 3.12.1будет у того, кто раньше нажмет коммит). Не то чтобы это было полным кошмаром конфигурационного управления, но и радости немного.

    Я бы рекомендовал остановиться на двухуровневой нумерации релизов. Если ваша команда обслуживает одного клиента (поддержка и развитие системы), то удобно сделать первым номером номер плановой итерации, а вторым номер патча к продакт-версии. Для коробок будет по-другому, но и там можно обойтись двумя номерами

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

    Так, например, пусть сейчас в эксплуатации находится версия 14.0 (или результат седьмой четырехнедельной итерации), в разработке находится 15.0, но при этом уже вышли патчи 14.1 и 14.2

    Полный номер версии в этом случае будет выглядеть aa.b.ccc, где:
    • aa – номер релиза
    • b – номер патча
    • ccc – номер сборки

    И у вас будет примерно такое соответствие:
    image


    • Версия 14.0.283 (релиз 14.0, сборка 283) стоит у клиента. На следующий релиз 16.0 запланировано исправить дефекты Д14 и Д16 и добавить фичи Ф10 и Ф11.
    • Команда приступает к работе, выпускает 15.0.284, с реализованными Ф10, Д14.
    • Но тут пользователи находят в 14.0.283 пару дефектов. Принято решение Д17 сделать патчем, а Д16 отложить до лучших времен. Выпускается патч 14.1.285
    • …
    • 15.0.289 и 16.0.289 идентичны. Отличие в номерах делается, для того, чтобы показать, что это официальный релиз.

    Такой способ нумерации достаточно удобен для многих случаев. Возможно, конкретно вашему проекту он не подходит. Самое главное, если будете что-то менять, помните, что есть описательные атрибуты и есть управляющие. Вы можете построить управление на других атрибутах, не относящихся к номеру версии. В этом случае номер можно упростить. А может быть и так, что всем все и так понятно и номер версии просто не нужен. Бывает и так. Впрочем, об этом или в другой статье или на тренинге.
    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 2

    Only users with full accounts can post comments. Log in, please.