You are here: Foswiki>Gnumed Web>ReleaseManagementRu (17 Mar 2013, IvanLykov)EditAttach

Управление релизом

Эта страница описывает предлагаемую процедуру для плавного выпуска новой версии.

Перед выпуском

Разработка (VCS HEAD)

Подготовка кандидатов релиза X.Y.rcN

ветка master

  • grep дерево экземпляров по старому имени базы данных и заменяет на новое при необходимости
  • pycommon/gmPG2.py:
    • добавляет хэш новой базы данных
    • изучает его, какие версии базы данных ожидаются для новой ветки клиента
  • создаёт сообщение Inbox с примечаниями к выпуску через сценарий SQL
  • make-release_tarball.sh: включает сценарии SQL для обновления
  • загружает и объединяет все новые переводы из Launchpad
  • настраивает client/gm-from-vcs.conf
  • создаёт ветку: git branch rc-X-Y

ветка rc-X-Y

(при необходимости, стирает/полоскает/повторяет)

  • git checkout rc-X-Y
  • git merge master
  • обновляет сообщение Inbox с примечаниями к выпуску
  • bootstrap-latest.sh/.bat: включает самую последнюю версию базы данных
  • bootstrap-latest.conf: включает самый последний upgrade-vN_vN+1.conf
  • upgrade-vN_vN+1.conf: ожидает новую версию базы данных вместо devel
  • сценарии client/doc/make-*.sh: ссылается на соответствующие базы данных
  • make-release_tarball.sh: устанавливает соответствующую версию базы данных и клиента X.Y.rcN
  • wxpython/gnumed.py: устанавливает версию клиента X.Y.rcN
  • проверяет основную функциональность (запуск !)
  • создаёт теги дерева: git tag rel-X-Y-rcN
  • повторно публикует руководство
  • создаёт архив
  • публикует кандидата выпуска в вашей загрузочной области
  • настраивает gm-versions.txt
  • обновляет общедоступную базу данных

Подготовка релиза X.Y.0

  • git checkout master

  • gm-net_upgrade_server.sh: ссылается на самую последнюю версию базы данных
  • bootstrap-latest.sh/.bat: включает самую последнюю версию базы данных
  • bootstrap-latest.conf: включает самый последний upgrade-vN_vN+1.conf

  • git tag -s rel-X-Y
  • git branch rel-X-Y-patches rel-X-Y (создаёт ветку из этого тэга)
  • git checkout rel-X-Y-patches
  • git merge rc-X-Y
  • git branch -d rc-X-Y

Выпускаемая версия X.Y.N

  • git checkout rel-X-Y-patches

(при необходимости, стирает/полоскает/повторяет)

  • обновляет сообщение Inbox с примечаниями к выпуску
  • gnumed/client/gnumed.py: устанавливает версию клиента X.Y.N
  • git add gnumed.py
  • dists/Linux/make-release_tarball.sh: устанавливает соответствующую версию клиента X.Y.N
  • dists/Linux/make-release_tarball.sh: включает сценарии SQL для исправлений (также в ветке master)
  • git add make-release_tarball.sh
  • запускает по меньшей мере минимальные тесты выпуска:
    • делает начальную загрузку базы данных (bootstrap-latest.sh)
    • обновляет базу данных (upgrade-db.sh)
    • исправляет базу данных (fixup-db.sh)
    • запускает клиент (gm-from-vcs.sh)
      • активирует пациента
      • активирует однократно каждую вкладку
      • регистрация нового пациента
  • git commit -v
  • git tag -s rel-X-Y-N
  • повторно публикует руководство
  • собирает архив
    • запускает dists/Linux/make-release_tarball.sh
  • загружает на "Savannah"
  • настраивает gnumed-versions.txt
  • обновляет страничку статуса выпуска
  • собирает пакеты для версии X.Y.N
    • пакет для Debian
    • установщик для Windows
    • RPM для Mandriva
    • RPM для Suse
    • электронная сборка Gentoo
    • образ DMG для MacOSX?
    • ... ?
  • включает обратную связь, исправляет ошибки

В ходе выпуска релиза

Анонсирование пакетов

список рассылки

сайты портала

прочее

После реализации выпуска

  • делаем перерыв
  • исправляем ошибки в rel-X-Y-Z-patches
  • ещё ожидаем
  • думаем о следующем выпуске


Схема управления версиями GNUmed

Версии определяются через соответствующий тэг в дереве CVS. Строка версии состоит из 3 часте:

  • версия major, текущая 0
  • версия minor, текущая 5
  • на уровне патча или кандидата выпуска

Функции вводятся между изменениями только младших версий. На уровне исправлений релиза никогда не будет новых функций, они будут только при получении исправления ошибки. Исправление ошибок применяются к HEAD CVS и только в последнем выпуске, поэтому рекомендуется оставаться в курсе выпущенных версий. На уровне патч-релиза также никогда не требуется изменений в базе данных.

Вот стратегия создания тэгов (после 0.4):

Для релиза будет готовится код. Предположим, что релиз должен быть v0.4.0. Ствол CVS (HEAD) помечается, как rel-0-4. Этот тег станет корневой веткой, на которой фактически будет происходить выпуск 0.4.0, в то время как HEAD может продолжать развиваться. Ветка rel-0-4-patches создаётся и помечается тегом rel-0-4. Только эта ветка когда-либо получит исправления ошибок. В этой ветке установлен тег rel-0-4-rc1, который затем будет выпущен, как v0.4.rc1.

После исправления ошибок в конечном итоге ветка помечается, как rel-0-4-0, которая получается выпущенной под v0.4.0. Далее ошибки исправляются и, в конечном итоге, ветка помечается, как rel-0-4-1, которая затем выпускается, как v0.4.1.

Со временем HEAD для CVS помечается, как rel-0-5, ответвлённая в rel-0-5-patches и цикл возобновляется.

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

Несколько устаревших сообщений -devel, которые предшествовали указанному выше, включают одно и другое.
Topic revision: 17 Mar 2013, IvanLykov
 
Download.png
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback
Powered by Olark