Пользователь
0,0
рейтинг
3 сентября 2014 в 12:49

Разработка → HHVM 3.3 — первый релиз с долгосрочной поддержкой (LTS) перевод

imageHHVM известен своей высокой скоростью развития: в настоящее время на Github попадает тот же код, что и используется для Facebook, а версии выпускаются каждые 8 недель. Это впечатляет, хотя и отталкивает, если думать об этом в контексте построения бизнеса или инфраструктуры.

Команда HHVM понимает, что для того, чтобы добиться большего охвата пользователи должны получить своего рода обязательство для того, чтобы быть уверенными в стабильности и безопасности уже выпущенных версий.

Соглашение


Начиная с версии 3.3, команда HHVM будет постоянно поддерживать 2 релиза (релизы с долгосрочной поддержкой, Long-Term Support) c разницей примерно в 6 месяцев (24 недели, если быть точным), что по факту даст эффективный цикл поддержки в почти год длинной. В качестве примера — HHVM 3.3, релиз которого намечен на 11 сентября 2014 года, будет поддерживаться до версии 3.9 (8 * 6 = 48 недель, около 11 месяцев). Соответственно 3.6 (должна выйти через 24 недели после 3.3) будет поддерживаться в течении следующих 6 релизов. Запутались? Взглянем на таблицу:

Название версии Предполагаемая дата релиза LTS? Конец поддержки
3.3 11 сентября 2014 да 13 августа 2015
3,4 * 6 ноября 2014 не
3.5 * 1 января 2015 не
3,6 * 26 февраля 2015 да 28 января 2016
3.7 * 23 апреля 2015 не
3.8 * 18 июня 2015 не
3.9 * 13 августа 2015 да 14 июля 2016
3.10 * 8 октября 2015 не
3.11 * 3 декабря 2015 не
3.12 * 28 января 2016 да 29 декабря 2016
3.13 * 24 марта 2016 не
3.14 * 19 мая 2016 не
3.15 * 14 июля 2016 да 15 июня 2017
* названия релиз пока не определены

Официальные дистрибутивы


Кроме вышесказанного, команда прикладывает большие усилия для продвижения официальных пакетов в основной архив Debian, откуда они должны попасть в репозитарии Debian-stable, Ubuntu, а также прочие основанные на Debian ОС. Есть намерение поддерживать поддерживать версии, которые попадут в LTS-релизы этих дистрибутивов, на всем его протяжении, выпуская исправления безопасности.

Также, несмотря на то, что ресурсы команды ограничены и пакеты для таких дистрибутивов как Fedora вряд ли попадут в официальный репозитарий, они будут поддерживаться.

Типы обновлений для LTS-релизов


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

Но стоит заметить, что LTS-релизы вряд ли будут получать серьезные обновления функционала. Исправления безопасности будут иметь наивысший приоритет, все остальное нужно будет рассматривать, балансируя между объемом работ по внесению исправлений, тестированию и выгодой от этих изменений.
Перевод: Ender is a Security Engineer at Facebook
Антон Кармазин @kriptomen
карма
39,0
рейтинг 0,0
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (3)

  • +3
    Все больше проектов перенимают такую систему релизов, привязанных к календарю. Не знаю, кто первым это начал, но посмотрите на список:

    Ubuntu — релиз каждые полгода, есть LTS-версии
    Chrome — релиз каждые 6 недель, есть несколько каналов обновления
    Firefox — релиз каждые 6 недель, есть LTS-версии и несколько каналов обновления
    Haskell Platform — релиз каждый год, опциональные релизы в течение года
    Ember.JS — релиз каждые 6 недель, несколько каналов обновления

    Есть планы по переходу на такой режим стандарта ECMAScript: релиз каждый год, WHAT WG тоже перешло на регулярный перевыпуск стандарта HTML5 (но там как таковых версий нет). В Node.js разработчики говорили о планах перейти на регулярные релизы после выпуска 1.0. В Django официально такой политики регулярных релизов нет, но по факту разработчики следуют четкому расписанию.

    В общем, примеров масса и со временем их становится больше.
  • +7
    Может кто нибудь поделится практическим опытом использования HHVM на реальных проектах?
  • +2
    Я тоже вчера в их блоге это увидел. Это очень важный эпизод т.к. до этого момента связываться с hhvm было просто опасно — можно было остаться один на один с недодерживаемой версией.
    Если кратко, то этот шаг частично нивелирует риски (с которыми я согласен), описанные здесь: blog.ircmaxell.com/2014/03/an-opinion-on-future-of-php.html

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.