Жизненный цикл версий
MediaWiki действует согласно модели развития «непрерывной интеграции», где изменения программного обеспечения на регулярной основе разворачиваются на веб-сайтах Wikimedia, таких, как Википедия.
В теории, новые крупные релизы выпускаются на ежеквартальной основе, и побочные ответвления и наследуемые версии продолжают получать обновления безопасности в течение года с первого релиза следующей версии. Из-за нехватки времени и быстрого рефакторинга базы кода, мы не можем бесконечно поддержать устаревшие релизы, обновления безопасности и критические обновления не применяются к версиям, которые достигли завершения жизненного цикла.
Релиз-менеджер настоятельно рекомендует операторам вики-проектов подписаться на список рассылки mediawiki-announce, чтобы получать уведомления обо всех релизах и обеспечить свои вики-проекты самой свежей версией программного обеспечения. Эти объявления также размещаются в mediawiki-l и wikitech-l.
Текущие версии и их жизненный цикл
| Версия | Состояние | Релиз | Окончание жизн. цикла |
|---|---|---|---|
| 1.44.x | будущая версия | ||
| 1.43.x (LTS) | текущая версия с долгосрочной поддержкой | ||
| 1.42.x | текущая стабильная версия | ||
| 1.41.x | наследуемая версия | ||
| 1.40.x | устаревшая версия | ||
| 1.39.x (LTS) | устаревшая версия с долгосрочной поддержкой | ||
| 1.38.x | устаревшая версия |
Версии, включенные в таблицу выше, которые помечены как устаревшие и версии, которые не перечислены в таблице, не получают каких-либо исправлений по безопасности. Это также включает все версии старше, чем самая старая из перечисленных версий. В них могут быть критические уязвимости безопасности и другие большие ошибки, включая угрозу возможности потери данных и/или повреждения. Менеджер по выпускам также строго рекомендовал использовать в работе только версии, перечисленные выше как «стабильная версия», «наследуемая версия» или «версия с долгосрочной поддержкой»(LTS).
- Альфа-разработка
- Разработка выпуска
- Стабильный выпуск
- Выпуск с долгосрочной поддержкой
Политика выхода релизов
- Каждый точечный выпуск (point release) будет включать обновленные файлы i18n, а также любые исправления ошибок. Никакие новые функции не будут перенесены обратно в точечные выпуски, и поддержка не обязательно включает встроенные расширения и скины в целом.
- Большой (major) релиз делается каждые шесть месяцев.
- Небольшие (minor) выпуски (включающие исправления безопасности, обратные порты перевода сообщений и общие исправления ошибок) будут выходить каждый квартал.
- Версия с долгосрочной поддержкой (LTS) будет создаваться каждые два года. Так получается перекрытие в один год в LTS-поддержке. Например, 1.23 поддерживалась до мая 2017 года. 1.27 выпущена за год до этого. Таким образом у людей есть год для перехода на новую версию LTS и 1 год, чтобы сделать переход.
- Примечания к выпуску по-прежнему будут основой для отображения того, что изменилось. Из-за характера проекта, управляемого волонтёрами, невозможно с уверенностью сказать, что произойдёт в следующие 6-12 месяцев.
График релизов
Этот график является задачами, которые необходимо сделать до выпуска новой версии. Дата фактического выпуска дается здесь как T (для "времени" релиза) и суффикс -# (для “количества недель до выпуска”).
| Связанная задача | Задача |
|---|---|
| T - 7 | Сообщите, что релизная ветка будет создана через недужное для для завершены функций находящихся в работе, объединено до этого. Создать "MW-X.XX-release" в Phabricator. |
| T - 6 | Создать ветку для ядра и всех расширений в Gerrit. |
| T - 5 | Применить метку X.XX-rc.0 и выпустить первоначальный релиз-кандидат. |
| T - 4 | Собрать любые сообщения об ошибках и обобщить их в почтовой рассылке. |
| T - 3 | Применить метку X.XX-rc.1 и выпустить второй релиз-кандидат. Любые новые расширения, которые предлагались для добавления в архив релиза, должны быть уже в нем к этому моменту. С этого момента никаких изменений в расширениях не производится. |
| T - 2 | Собрать любые сообщения об ошибках, применить (merge) исправления, отменить новые, неполные возможности, которые были случайно включены. Применить метку X.XX-rc.2 и выпустить третий релиз-кандидат. |
| T - 1 | Повторить предыдущие шаги. Использовать метку X.XX-rc.final для выпуска финального релиза. С этого момента не принимаются бэкпорты. |
| T | Отметить (TAG) репозиторий меткой X.XX и сделать релиз. |
Управление жизненным циклом расширений
Большинство установок MediaWiki включают значительное количество расширений (вики-сайты Викимедиа часто имеют около 140). Управление исправлением ошибок обслуживания расширений и выбор правильной версии расширения в случаях, когда ОСНОВНАЯ версия разработки опирается на функции, еще не доступные в стабильном или устаревшем ядре MediaWiki, может быть сложной задачей.
Поэтому разработчикам расширений настоятельно рекомендуется для каждой версии MediaWiki делать соответствующую версию расширения.
(Для более подробной информации смотрите Совместимость#Расширения MediaWiki.)
Для расширений, размещенных в git-репозиториях Викимедиа, такие ветки (с такими именами, как REL1_30 для MediaWiki 1.30) создаются автоматически из мастера при разветвлении новой версии MediaWiki (при условии, что мастер расширения совместим с Мастер MediaWiki на все времена).
Однако предпочтительнее, чтобы сопровождающий расширения исправлял ошибки не только в ОСНОВНОЙ, но и в устареыших стабильных и стабильных версиях (при необходимости перенося исправление в старые ветки).
Цель этих правил состоит в том, чтобы люди или организации, устанавливающие MediaWiki, могли положиться на установку новейшей версии версии и сопоставление расширений простым способом, например, для ядра 1.20.x, обратившись к REL1_20 в git.
И это позволяет избежать архивов и zip-файлов с неуместными и непредсказуемыми именами.
Смотрите также
- Информация о совместимости для MediaWiki, особенно важно PHP и MySQL
- Политика стабильного интерфейса
- Generators on WikiApiary - статистика использования различных версий версий MediaWiki.