А на моей машине все работает!
Из ненормативной лексики программистов.
Для того, чтобы программисты, тестировщики и пользователи программы могли понимать где и что происходит, где произошла ошибка или когда можно посмотреть на новую фичу, применяют версии программы. Самый простой способ — это одно число, увеличивающееся на единицу каждую сборку. Иногда этот метод наилучший. А что в других продуктах?
У моего 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 – номер сборки
И у вас будет примерно такое соответствие:
• Версия 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 идентичны. Отличие в номерах делается, для того, чтобы показать, что это официальный релиз.
Такой способ нумерации достаточно удобен для многих случаев. Возможно, конкретно вашему проекту он не подходит. Самое главное, если будете что-то менять, помните, что есть описательные атрибуты и есть управляющие. Вы можете построить управление на других атрибутах, не относящихся к номеру версии. В этом случае номер можно упростить. А может быть и так, что всем все и так понятно и номер версии просто не нужен. Бывает и так. Впрочем, об этом или в другой статье или на тренинге.
Из ненормативной лексики программистов.
Для того, чтобы программисты, тестировщики и пользователи программы могли понимать где и что происходит, где произошла ошибка или когда можно посмотреть на новую фичу, применяют версии программы. Самый простой способ — это одно число, увеличивающееся на единицу каждую сборку. Иногда этот метод наилучший. А что в других продуктах?
У моего 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 – номер сборки
И у вас будет примерно такое соответствие:
• Версия 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 идентичны. Отличие в номерах делается, для того, чтобы показать, что это официальный релиз.
Такой способ нумерации достаточно удобен для многих случаев. Возможно, конкретно вашему проекту он не подходит. Самое главное, если будете что-то менять, помните, что есть описательные атрибуты и есть управляющие. Вы можете построить управление на других атрибутах, не относящихся к номеру версии. В этом случае номер можно упростить. А может быть и так, что всем все и так понятно и номер версии просто не нужен. Бывает и так. Впрочем, об этом или в другой статье или на тренинге.
