.NET 11 RC2: что означает go-live и что проверить у приложения

.NET 11 RC2 вышел с go-live support license, допускавшей использование в production. Но этот статус не бессрочен: на 27 октября 2026 года политика Microsoft уже указывает окончание поддержки RC2 25 октября и переход к RC3. Поэтому сейчас RC2 нужно рассматривать вместе с актуальным планом обновления, а не рекомендовать по одному первоначальному анонсу.

Анонс и текущая политика отвечают на разные вопросы

Анонс .NET 11 RC2 от 13 октября 2026 года прямо сообщал о go-live support license и возможности production. Это отличает выпуск от обычного preview. Нельзя автоматически переносить на него запрет другого производителя только потому, что в названии есть RC.

Политика поддержки Microsoft, обновлённая 25 октября, объясняет, что go-live выпуски поддерживаются в production, и приводит отдельные периоды. Для RC2 указан конец 25 октября; для RC3 — период с 25 октября до 10 ноября. Историческое разрешение и актуальная поддержка конкретной сборки должны проверяться вместе.

Что go-live не подтверждает за владельца приложения

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

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

Ведомость поставки вместо одной версии .NET

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

Учебная ситуация: отчёт о готовности устарел за время согласования

Представим вымышленный внутренний инструмент. Команда проверила поставку на RC2, сохранила ссылку на go-live и передала отчёт на согласование. Пока решение обсуждали, политика поддержки изменилась. Сам старый тест не становится ложным, но он больше не отвечает на вопрос, какую поддерживаемую поставку выпускать сегодня.

В таком случае сохраните результаты как историю и определите разницу с выбранным следующим выпуском. Повторять нужно те проверки, применимость которых затронута изменением. При этом статус «уже тестировали .NET 11» слишком общий: в отчёте должны различаться проверенная сборка и планируемая поставка.

Что проверить перед рабочим решением

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

Если приложение использует экспериментальный API, go-live всей платформы не превращает этот API в стабильный контракт. Его статус рассматривают отдельно. Точно так же результаты производителя по памяти или скорости не нужно выдавать за измерения своей программы.

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