Кратко

  • Решение принять отдельное исправление в стабильную ветку отличается от решения продолжать сопровождение старой серии.
  • Kernel.org связывает срок такой поддержки с потребностями пользователей и доступностью сопровождающих. Прогнозная дата окончания не является коммерческой гарантией.

Старая версия ядра может оставаться нужной устройству спустя годы после выпуска. Но это не означает, что в её стабильную ветку попадёт любое предложенное исправление или что её будут сопровождать столько же, сколько продаётся продукт. В Linux здесь действуют два разных фильтра. Если их смешать, маркировка версии начинает выглядеть как обещание, которого никто не давал.

Первый фильтр относится к каждому патчу. Правила стабильного ядра требуют, чтобы исправление или эквивалент уже находились в основной ветке. Оно должно быть очевидно корректным и протестированным, занимать не более 100 строк вместе с контекстом, соответствовать правилам отправки патчей и устранять реальную проблему пользователя либо добавлять идентификатор устройства. В примерах названы аварийное завершение работы, зависание, повреждение данных, реальная уязвимость, особенности оборудования и ошибки сборки. Правила исключают теоретические риски без объяснения, как их можно использовать, а также изменения без пользы для пользователей. Такие ограничения упрощают проверку обратного переноса и снижают риск добавить новый дефект в уже работающую ветку. Правила стабильной ветки описывают критерии и порядок подачи.

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

Второй фильтр определяет срок жизни самой ветки. Kernel.org описывает долгосрочные серии как старые деревья, которым продолжают поставлять важные исправления, обычно реже, чем в активные стабильные ветки. При выборе учитываются крупные новые возможности, потребности коммерческих дистрибутивов, спрос производителей устройств, загрузка сопровождающих и наличие у них времени. Для новой долгосрочной серии сначала указывается прогнозный срок окончания. Его могут продлить, если интерес отрасли помогает поддержать более длительное сопровождение. На странице прямо сказано, что прогноз не закреплён навсегда. Проверенная для этой статьи копия страницы помечена датой 25 февраля 2026 года: описание политики применимо, но опубликованный список версий нельзя считать состоянием на октябрь 2026-го. Страница выпусков Kernel.org описывает факторы выбора и прогнозные сроки.

Роль Greg Kroah-Hartman важна, но она не делает его единственным владельцем всей системы. Linux Foundation называет его Fellow, сопровождающим стабильную ветку Linux и несколько подсистем. Документ о процессе разработки ядра указывает Greg и Sasha Levin в составе стабильной команды и описывает участие профильных сопровождающих и рецензентов. В интервью 2018 года Greg вспоминал, что был одним из разработчиков, добровольно взявшихся за стабильные выпуски, когда они начались в 2005 году. Он также рассказывал, что со временем стал одновременно сопровождать больше веток, и связывал эту работу с безопасностью устройств, уже находящихся в эксплуатации. Это его ретроспективный рассказ, а не актуальный подсчёт веток и не доказательство того, что именно он один выбирает каждую долгосрочную серию. Профиль Linux Foundation, документ о процессе разработки ядра и интервью с Greg показывают роль и её границы.

Для оператора это различие меняет смысл маркировки поддержки. Долгосрочная ветка Kernel.org — это линия сопровождения сообщества. Дистрибутив может выпускать основанное на ней ядро, добавлять собственные изменения или вести другое дерево по своему графику. Kernel.org направляет пользователей дистрибутивных ядер в службу поддержки их дистрибутива и предупреждает, что разработчики ядра могут не поддерживать такие сборки. Поэтому оператору нужно установить, кто сопровождает точное ядро в развёрнутом образе, как обрабатываются исправления безопасности и регрессии и покрывает ли обязательство поставщика весь срок эксплуатации продукта. Одна метка LTS не отвечает на эти договорные вопросы. FAQ Kernel.org и страница выпусков разграничивают эти области поддержки.

Экономический механизм прост, хотя номер версии может его скрыть. Каждая серия, которую продолжают поддерживать, требует работы: кому-то нужно оценивать исправления, проверять обратные переносы, тестировать выпуски и разбирать регрессии. Публичные источники не приводят оценок трудозатрат или стоимости. Но они показывают, что спрос со стороны пользователей и доступность сопровождающих влияют на то, какие серии получают более длительное внимание. Спрос отрасли может оправдать затраты, но не заменяет людей, которые выполняют эту работу.

Note 64 Хэнга Лу предлагает полезный аналитический вопрос: документ координации может описать будущее состояние, но сам по себе не вводит его в эксплуатацию. Эта статья не утверждает, что Linux проектировался по принципам той заметки. Если использовать её лишь как ограниченную оптику, становится понятнее, почему слова «долгосрочная поддержка» и прогнозная дата не работают как самореализующаяся гарантия. Они описывают договорённость, которую участники должны продолжать принимать и поддерживать. Note 64 — аналитическая ссылка, а не источник о политике ядра.

Анализ

Два фильтра распределяют риски на разных уровнях. Правила для патчей ограничивают изменения в существующей ветке; выбор долгосрочных серий ограничивает число старых веток, которые сообщество может продолжать сопровождать. Более строгие правила не создают дополнительной многолетней рабочей ёмкости, а сильный спрос отрасли не делает безопасным непроверенный перенос. Практическое обязательство существует, только пока пригодность исправления и возможность поддерживать его ветку сохраняются одновременно.

Этот горизонт зависит от состава участников, который может меняться. Производителям устройств могут быть нужны старые ядра для уже поставленной техники, дистрибутивам — стабильная основа для выпуска, а сопровождающим необходимо время на проверку и тестирование. Публичные источники не показывают распределение таких вложений и переговорный вес каждого участника. Они указывают, что срок поддержки определяется спросом и доступной работой, а не одним лишь возрастом версии.

Источники