Qt 6.12 LTS: пять лет поддержки и обязанности команды

Qt 6.12 LTS обещает пятилетнее сопровождение ветки, но не автоматическую пятилетнюю поддержку любой программы на Qt. Между исправлением библиотеки и обновлением у заказчика остаются доступ к нужной поставке, работа команды, проверка и доставка. Эти обязанности стоит согласовать до выбора LTS как основания долгосрочного продукта.

Что заявлено производителем

Qt 6.12 LTS выпущен 30 сентября 2026 года. В анонсе указан пятилетний период maintenance. Страница условий LTS относит доступность LTS к Commercial Qt licenses. Поэтому фразу «пять лет исправлений бесплатно для любой лицензии» из этих страниц вывести нельзя.

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

Четыре вопроса перед договором сопровождения

• Доступ: кто владеет применимой лицензией и получает поддерживаемые выпуски?
• Разработка: кто оценивает влияние исправления и выпускает новую версию программы?
• Приёмка: кто подтверждает работу нужных функций на поддерживаемых устройствах?
• Доставка: кто обеспечивает получение обновления пользователями и видит результат?

Если все ответы сводятся к «это делает Qt», цепочка не описана. Производитель библиотеки не знает ваши бизнес-сценарии, способ распространения и договорённости с заказчиком. Даже подходящая лицензия не назначает ответственного за выпуск конечного приложения.

Матрица ответственности за исправление

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

Учебный пример: библиотеку обновили, продукт ещё нет

Представим условную программу учёта для филиалов. Исправленный выпуск Qt доступен разработчику, тестовая сборка подготовлена, но филиалы получают обновления через собственный согласованный процесс. До завершения этого процесса нельзя записать, что исправление уже применяется всеми пользователями. Это вымышленный пример границы сопровождения, а не статистика студии.

Заказчику полезно видеть раздельные состояния: исправление найдено, принято в работу, включено в поставку, проверено, доставлено. Общая зелёная отметка «поддерживается до конца LTS» не показывает, на каком переходе остановилась конкретная работа.

Что зафиксировать на срок жизни продукта

1. Опишите нужные платформы, модули и условия доступа к исправлениям.
2. Назначьте ответственных за оценку, проверку и выпуск приложения.
3. Согласуйте критические пользовательские операции для приёмки.
4. Укажите способ распространения и подтверждения установленной версии.
5. Сохраните воспроизводимое окружение и доступ к исходникам.
6. Назначьте момент пересмотра плана до окончания выбранного сопровождения.

Не подменяйте сроками LTS обещание отсутствия ошибок. Новая версия зависимости может требовать проверки собственного кода, а внешняя система — отдельного обновления. Долгосрочный план полезен именно тем, что делает эту работу предусмотренной, а не неожиданной.

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