Релиз-кандидат

Релиз-кандидат (англ. release candidate, сокр. RC) — это версия программного обеспечения, которая находится на финальной стадии разработки и предназначена для всестороннего тестирования перед официальным выпуском (релизом). Релиз-кандидат считается потенциально готовым к коммерческому использованию продуктом, но при этом допускает наличие критических ошибок, которые могут быть выявлены в ходе финального цикла проверок. Если в процессе тестирования RC не обнаруживается серьёзных дефектов, данная версия становится финальным релизом (RTM — Release to Manufacturing или GA — General Availability). В противном случае выпускается исправленный релиз-кандидат (RC2, RC3 и т. д.), и цикл повторяется.

История термина и развитие практики

Понятие «релиз-кандидат» возникло в индустрии разработки программного обеспечения в 1980-х годах, когда процессы управления версиями стали более формализованными. До этого разработчики часто выпускали «бета-версии», которые могли содержать значительные недоработки, и «финальные версии», которые не всегда были стабильными. Введение промежуточного статуса RC позволило чётко разделить этапы: альфа-версия (внутреннее тестирование), бета-версия (публичное тестирование с активным поиском ошибок) и релиз-кандидат (последняя проверка перед массовым выпуском).

В 1990-х годах, с распространением операционных систем семейства Windows (например, Windows 95 и Windows NT), корпорация Microsoft активно использовала термин «Release Candidate» для обозначения предварительных сборок, которые распространялись среди ограниченного круга тестеров. В 2000-х годах практика стала общепринятой в сообществах разработчиков открытого ПО (Linux, Mozilla Firefox, LibreOffice) и коммерческих компаний (Apple, Google). В настоящее время релиз-кандидаты являются стандартным этапом в жизненном цикле практически любого крупного программного продукта.

Цели и задачи релиз-кандидата

Основная цель выпуска релиз-кандидата — минимизация рисков, связанных с выпуском нестабильного продукта. Задачи, решаемые на этом этапе:

• Финальное тестирование: проверка совместимости с различными аппаратными и программными конфигурациями, а также сценариями использования.
• Выявление регрессий: ошибок, которые могли быть внесены в процессе исправления предыдущих дефектов.
• Валидация документации: проверка соответствия руководств пользователя и технической документации актуальному поведению программы.
• Сбор отзывов: от ограниченной группы пользователей (часто — участников программ предварительного доступа) для оценки удобства и производительности.
• Принятие решения о релизе: если за установленный период (обычно от нескольких дней до нескольких недель) не поступает сообщений о критических ошибках, версия RC получает статус финальной.

Отличие от других стадий разработки

Релиз-кандидат занимает строго определённое место в иерархии версий:

• Альфа-версия (Alpha): ранняя сборка, предназначенная для внутреннего тестирования разработчиками. Может содержать множество неработающих функций и грубых ошибок.
• Бета-версия (Beta): публичная версия, распространяемая для широкого круга тестеров. Основная цель — сбор отзывов о функциональности и выявление ошибок, но стабильность не гарантируется.
• Релиз-кандидат (RC): предрелизная версия, в которой разработчики считают, что все запланированные функции реализованы, а критические ошибки устранены. Отличается от бета-версии более высокой стабильностью и меньшим объёмом изменений.
• Финальный релиз (RTM/GA): версия, официально выпущенная для всех пользователей. Считается стабильной и готовой к промышленной эксплуатации.

Процесс выпуска и нумерация

Обычно выпуск релиз-кандидата происходит по следующему сценарию:

1. Разработчики завершают реализацию всех запланированных функций и проводят внутреннее тестирование.
2. Собирается версия RC1, которая передаётся группе тестирования (QA-отделу или доверенным бета-тестерам).
3. В течение определённого времени (например, 2–4 недели) собираются отчёты об ошибках.
4. Если найдены серьёзные дефекты, выпускается RC2 с исправлениями. Процесс может повторяться несколько раз (RC3, RC4 и т. д.).
5. Если за отведённый срок не поступает сообщений о критических проблемах, версия RC объявляется финальной и переименовывается в RTM.

Нумерация релиз-кандидатов может быть как последовательной (RC1, RC2, RC3), так и включать номер сборки (например, 10.0.19041.1 RC). В некоторых проектах (например, в ядре Linux) используется термин «release candidate» для обозначения стабильных версий, которые проходят дополнительное тестирование перед выпуском.

Примеры использования

Релиз-кандидаты широко применяются в различных категориях программного обеспечения:

• Операционные системы: Microsoft Windows 10 и Windows 11 выпускали несколько RC-сборок в рамках программы Windows Insider. Например, сборка 21390 была релиз-кандидатом для Windows 10 версии 21H2.
• Офисные пакеты: LibreOffice регулярно выпускает RC-версии перед каждым мажорным обновлением (например, LibreOffice 7.5 RC1).
• Веб-браузеры: Mozilla Firefox использует каналы «Release Candidate» для финальной проверки перед выпуском стабильной версии.
• Игровые движки и игры: многие крупные игровые проекты (например, Cyberpunk 2077 или The Witcher 3) выпускали RC-версии для консолей и ПК для тестирования производительности.
• Системы управления контентом: WordPress перед каждым мажорным релизом (например, 6.0) выпускает RC-версии для проверки совместимости с плагинами и темами.

Критика и ограничения

Несмотря на широкое распространение, практика использования релиз-кандидатов имеет ряд недостатков:

• Ложное чувство готовности: пользователи могут воспринимать RC как финальную версию и использовать её в производственной среде, что приводит к сбоям.
• Ограниченное тестирование: из-за того, что RC распространяется среди ограниченного круга лиц, некоторые ошибки могут остаться незамеченными.
• Временные задержки: если в RC обнаруживается критическая ошибка, выпуск финального продукта может быть отложен на неопределённый срок.
• Сложность управления версиями: при большом количестве RC-выпусков (например, RC5, RC6) возникает путаница в нумерации и отслеживании изменений.

В некоторых проектах (например, в методологии непрерывной поставки — Continuous Delivery) отказываются от выделенного этапа RC, предпочитая автоматизированное тестирование и постепенное развёртывание обновлений.

Интересные факты

• В сообществе разработчиков ядра Linux термин «release candidate» используется для обозначения версий, которые проходят дополнительное тестирование перед выпуском стабильной версии. Например, ядро 5.10-rc1 было первым релиз-кандидатом для версии 5.10.
• В некоторых компаниях (например, в Google) вместо RC применяется термин «Release Preview» (RP), который по сути является аналогом.
• В проектах с открытым исходным кодом (например, в Apache OpenOffice) RC-версии часто распространяются через официальные зеркала для скачивания, но с пометкой «не для производственного использования».
• В игровой индустрии релиз-кандидаты иногда называют «Gold Master Candidate» (GMC), особенно когда речь идёт о физических носителях (дисках).

Источники

• Microsoft Developer Network (MSDN) — документация по жизненному циклу разработки программного обеспечения.
• The Linux Kernel Archives — описание процесса выпуска версий ядра.
• LibreOffice Release Notes — официальные примечания к выпускам.
• Mozilla Wiki — описание каналов распространения Firefox.
• ISO/IEC 12207:2008 — стандарт на процессы жизненного цикла программного обеспечения.