Какими бывают версии программ и стадии жизненного цикла ПО

Версия программы — это зафиксированное состояние продукта под уникальной меткой (номером выпуска или названием стадии), по которой один выпуск отличают от другого. Тема часто путается, потому что под словом «версия» смешивают три разные вещи. Ниже разведем их и разберем каждую: номер версии, стадию готовности выпуска и жизненный цикл ПО целиком.

Чтобы дальше не путаться, зафиксируем три понятия сразу:

• Номер версии — идентификатор конкретного выпуска, например 2.4.1. Отвечает на вопрос «какой это выпуск».
• Стадия (канал) готовности — насколько выпуску можно доверять: alpha, beta, release candidate, стабильный. Отвечает на «готов ли он к реальной работе».
• Жизненный цикл ПО (SDLC) — весь путь продукта от идеи до снятия с поддержки. Отвечает на «на каком этапе находится продукт в целом».

Одна и та же сборка описывается всеми тремя осями сразу. Например, выпуск 1.0.0-rc.1 — это номер (1.0.0-rc.1), стадия готовности (release candidate) и этап жизненного цикла (тестирование перед первым релизом) одновременно.

Номер версии: как устроен SemVer

Самая распространенная схема номеров — семантическое версионирование (SemVer). Номер состоит из трех чисел через точку: MAJOR.MINOR.PATCH, например 2.4.1. Спецификация SemVer 2.0.0 связывает каждое число с типом изменений:

• MAJOR (2) — несовместимые изменения API: код, работавший на 1.x, может сломаться.
• MINOR (4) — новая функциональность с сохранением обратной совместимости.
• PATCH (1) — исправления багов без изменения поведения.

К номеру можно добавить метку предрелиза через дефис и метаданные сборки через плюс: 1.0.0-beta.2+build.145. Метка -alpha, -beta, -rc.1 означает, что выпуск еще не считается стабильным; часть после плюса на приоритет версий не влияет.

SemVer — соглашение, а не единственный стандарт. Календарное версионирование (CalVer) кодирует дату: номер дистрибутива Ubuntu 24.04 — это год и месяц выпуска. Часть проектов использует простую сквозную нумерацию. Схему выбирают под продукт, а не по универсальному правилу.

Сравнение номеров релизов (без предрелизных меток) сводится к сравнению чисел по разрядам:

def parse(v):
    # "2.4.1" -> (2, 4, 1); работает для релизов без меток -alpha/-rc
    return tuple(int(x) for x in v.split("."))

print(parse("2.4.1") > parse("2.4.0"))  # True: patch выше
print(parse("2.4.1") < parse("2.5.0"))  # True: minor старше любого patch

Граница примера: для предрелизов правило сложнее. По спецификации SemVer выпуск с меткой младше такого же без метки, а сами метки упорядочены 1.0.0-alpha < 1.0.0-beta < 1.0.0-rc.1 < 1.0.0. Наивное сравнение чисел этого не учитывает; для полного разбора берут готовые библиотеки (например, packaging в Python или node-semver).

Стадии готовности: от pre-alpha до стабильного релиза

Стадия показывает, насколько выпуску можно доверять. Она может объявляться официально (канал в магазине приложений) или использоваться внутри команды негласно.

• Pre-alpha — все, что до первой альфы: проектирование, анализ требований, написание кода, отладка отдельных модулей. Часть функций еще не реализована; обычным пользователям такую сборку не отдают.
• Alpha — тестирование внутри команды или узкого сообщества. Функциональность активно дополняется, и к концу стадии ее обычно «замораживают», переходя к стабилизации.
• Beta — публичное тестирование широким кругом. Продукт относительно стабилен, но багов еще много, и пользователи фактически помогают их находить. Работа с бетой идет на свой риск.
• Release candidate (RC) — кандидат в стабильный выпуск. Критические и крупные ошибки исправлены; если за отведенное время серьезных дефектов не находят, RC становится релизом.
• Стабильный релиз — выпуск, прошедший все стадии и рекомендованный для повседневного использования.

Отдельный случай — вечная бета: продукт годами остается в бета-стадии. Термин связывают с описанием паттернов Web 2.0 у Тима О’Райли. Известный пример — почта Gmail, которая носила метку beta около пяти лет (примерно с 2004 по 2009 год), оставаясь при этом массовым рабочим сервисом. Так делают, когда сервис постоянно обновляется на стороне провайдера и «финальной» точки у него по сути нет.

Что происходит после релиза: RTM, GA и поддержка

Когда продукт прошел предварительные стадии, начинается выпуск. У него есть несколько формальных обозначений в зависимости от способа доставки:

• RTM (Release to Manufacturing) — сборка признана готовой к тиражированию; исторически — к записи на физические носители.
• GA (General Availability) — продукт официально доступен всем, включая коммерческую покупку.
• RTW (Release to Web) — выпуск через интернет, основной способ доставки сегодня.

После релиза начинается поддержка: выходят патчи (PATCH-версии) и пакеты обновлений. Срок поддержки не универсален — у одних продуктов это год-два, у других (в частности, релизы с долгой поддержкой, LTS) — пять и более лет. В конце пути наступает EOL (end of life) — прекращение поддержки, после которого обновления, включая исправления безопасности, больше не выходят.

Жизненный цикл ПО целиком

Жизненный цикл (SDLC) охватывает продукт от идеи до снятия с поддержки. Типичные этапы:

1. Планирование и анализ требований — что и зачем делаем.
2. Проектирование — архитектура и ключевые решения.
3. Разработка — написание кода.
4. Тестирование — здесь и живут стадии alpha/beta/RC.
5. Релиз и развертывание — RTM/GA/RTW.
6. Поддержка и сопровождение — патчи и обновления.
7. Снятие с поддержки — EOL.

Это модель, а не жесткая последовательность. В водопадной модели этапы идут строго по порядку; в гибких подходах (Agile, итеративная разработка) они повторяются короткими циклами, и продукт много раз проходит связку «разработка -> тестирование -> релиз» в пределах одного мажорного номера. Стадии готовности и номера версий — это разметка внутри жизненного цикла, а не отдельный от него процесс.

Как это связано: один продукт по шагам

Проследим условный продукт сразу по всем трем осям:

• 0.3.0-alpha.1 — внутренняя alpha, этап разработки; ноль в MAJOR подчеркивает, что API нестабилен.
• 1.0.0-rc.1 — release candidate, этап тестирования перед первым публичным релизом.
• 1.0.0 — первый стабильный релиз, этап GA.
• 1.2.0 — добавили функции с обратной совместимостью (рост MINOR), этап поддержки.
• 1.2.1 — исправили баг (рост PATCH).
• 2.0.0 — несовместимое изменение API (рост MAJOR); для пользователей 1.x это повод проверить свой код перед обновлением.

По одному номеру видно и стадию, и характер изменения: ноль в MAJOR или метка -rc говорят «еще не для продакшена», а рост MAJOR — «возможны поломки при обновлении».

Выводы

• Номер версии, стадия готовности и жизненный цикл — три разные оси; одна сборка описывается всеми сразу.
• SemVer кодирует смысл изменения: MAJOR — несовместимость, MINOR — новые функции, PATCH — исправления; но это соглашение, есть также CalVer и другие схемы.
• Стадии alpha -> beta -> RC -> стабильный отражают рост доверия к выпуску, а не величину номера.
• После релиза продукт живет в поддержке до EOL; LTS-релизы поддерживают дольше обычных.
• Ноль в MAJOR и метки предрелиза (-alpha, -rc) — явный сигнал, что версию рано ставить в продакшен.

Где применяется / связь с практикой

Смежные темы: Какими бывают ошибки в приложениях.

FAQ

Чем версия отличается от номера сборки (build)?
Версия — это внешний идентификатор выпуска для пользователей (2.4.1), а номер сборки — внутренний счетчик компиляции. В SemVer его выносят в метаданные после плюса (+build.145), и на приоритет версий он не влияет.

Что означает ноль в начале номера, например 0.9.0?
Ведущий ноль в позиции MAJOR по SemVer означает начальную разработку: публичный API считается нестабильным и может меняться в любой MINOR-версии без гарантий совместимости.

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