И на моей машине все работает! От ненормативной лексики программистов.
Чтобы программисты, тестировщики и пользователи программ понимали, где и что происходит, где произошла ошибка или когда стоит посмотреть новую функцию, используются версии программы.
Самый простой способ — это одно число, увеличивающееся на единицу при каждой сборке.
Иногда этот метод является лучшим.
Что есть в других продуктах? Мой номер версии IE — 8.0.6001.18828, а Paint — версии 6.0, но номер сборки — 6002. Следующий синтаксис используется для указания номеров версий продуктов Microsoft Office: аа.
bbbb.cccc * aa: Версия для офиса.
* bbbb: Версия исполняемого файла программы, например Excel.exe. * cccc: версия файла Mso.dll. Но Дональд Кнут сделал самую оригинальную вещь.
Начиная с версии 3.0, TeX использует особую систему нумерации версий: каждое обновление добавляет дополнительную десятичную цифру к номеру версии, так что он асимптотически приближается к π.
Это отражает тот факт, что текущая версия TeX — 3.1415926 — очень стабильна и возможны лишь незначительные обновления (см.
Давайте пока забудем о шутке Кнута.
Как это удобнее? В его семинар по настройке бактеритрекера Я говорю о различных группах атрибутов.
Есть описательные атрибуты, а есть управляющие.
Версия сборки важна для определения места обнаружения ошибки.
В данном случае это часть описания дефекта, мало чем отличающаяся от описания раздела программы или типа ошибки.
Также удобно использовать номер сборки, в которой был исправлен дефект (добавлена новая функция).
И здесь удобнее всего использовать одно единственное число, растущее от сборки к сборке.
Но для управления функциями и дефектами удобно использовать официальный номер релиза.
Соберем задачи на четырехнедельную итерацию.
Сейчас вышел релиз 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 планируется исправить дефекты D14 и D16 и добавить функции F10 и F11. • Команда приступает к работе, выпускает версию 15.0.284 с реализованными F10, D14. • Но и здесь пользователи находят пару недочетов в версии 14.0.283. Было решено сделать Д17 патчем, а Д16 отложить до лучших времён.
Вышел патч 14.1.285 • … • 15.0.289 и 16.0.289 идентичны.
Разница в цифрах сделана для того, чтобы показать, что это официальный релиз.
Такой способ нумерации весьма удобен во многих случаях.
Возможно, он не подойдет для вашего конкретного проекта.
Самое главное, если вы что-то меняете, помните, что есть атрибуты описательные, а есть контрольные.
Вы можете построить контроль на других атрибутах, кроме номера версии.
В этом случае число можно упростить.
А может быть, все уже все понимают и номер версии просто не нужен.
Такое тоже случается.
Однако подробнее об этом в другой статье или тренинге.
Теги: #программирование #тестирование #управление задачами #управление конфигурацией #контроль версий #управление сборкой #Чулан
-
Сколько Вы Экономите, Пополняя Запасы?
19 Oct, 24 -
Лучшая Компания По Дизайну Веб-Сайтов, Индия
19 Oct, 24 -
Обзор Системы Мониторинга Приложений Instana
19 Oct, 24 -
Иконочные Шрифты Для Мобильных Устройств
19 Oct, 24 -
Вы Не Google
19 Oct, 24
