Жизненный цикл успешного программного продукта может растянуться на годы, и за это время он проходит через множество трансформаций — от мелких исправлений до полной перестройки архитектуры. Чтобы пользователи и разработчики понимали, какое состояние системы перед ними, сохранив при этом узнаваемое название, применяют версионирование. Версия — это «подназвание», которое фиксирует конкретный этап развития ПО.
Суть и значение нумерации версий
Нумерация версий — это упорядоченная система присвоения уникальных идентификаторов разным состояниям продукта. Обычно это последовательность чисел или букв, растущая по мере развития проекта. Главная задача версионирования — дать понятное средство отслеживания изменений, чтобы пользователи могли сравнивать свои копии с новыми выпусками, а разработчики — управлять кодом и зависимостями.
Выбор конкретной схемы зависит от нескольких факторов: от инструментов разработки и систем контроля версий, от частоты релизов и желаемой степени детализации. Тяжёлые, редкие релизы обычно выдерживают простую схему, тогда как часто обновляемые продукты требуют более точной нумерации. Важны также совместимость протоколов, форматов и расширений, потребность в машиночитаемости для управления зависимостями и маркетинговые соображения.
Распространенные схемы нумерации
Единого стандарта нет, поэтому проекты выбирают подход, который лучше подходит под их цели и практики.
Последовательные номера
Ранние программы часто получали простые целые номера — 1, 2, 3 — по аналогии с изданиями книг. Этот способ всё ещё применим к редким стабильным релизам, например отдельным операционным системам или графическим редакторам. Мелкие сервисные правки в таких продуктах обычно не отражаются в видимом номере версии.
Десятичная дробь
Формат в виде десятичной дроби разделяет незначительные и крупные изменения: 1.0 — первый выпуск, 1.1 — небольшое обновление, 2.0 — крупное расширение функциональности. Иногда разработчики прыгают, например, с 2.0 на 2.5, чтобы подчеркнуть набор важных, но не радикальных нововведений. Для предварительных выпусков используют номера меньше единицы: 0.1, 0.9 и т. п.
Последовательность чисел (Major.Minor.Patch)
В этой схеме обычно выделяют три уровня версии:
- major — глобальные изменения, которые могут ломать обратную совместимость;
- minor — добавление функционала при сохранении совместимости;
- patch — исправление ошибок без изменения API.
При увеличении одного из чисел последующие обычно сбрасываются в ноль. Например, после 1.0.2 следует 1.1.0. Иногда добавляют четвертый элемент — номер сборки, который растёт с каждой компиляцией или берётся из системы контроля версий.
Буква в качестве младшей версии
Иногда вместо третьего числа используют буквы: 6.42 → 6.42b → 6.42c. Это показывает, что функциональность осталась прежней, но внесены отдельные правки.
Указание стадии разработки
При активной разработке принято помечать уровень зрелости выпуска:
- альфа-версия — ранняя внутренняя сборка;
- бета-версия — доступная для внешнего тестирования;
- выпуск-кандидат — потенциально готовая к релизу версия;
- окончательный выпуск — готовый к широкому распространению релиз.
Последовательность может выглядеть так: 2.0 alpha1 < 2.0 beta < 2.0 rc1 < 2.0. В отдельных схемах ноль в первом или третьем числе служит маркером бета-версии или внутреннего релиза.
Алфавитно-цифровое название и дата
Долгоживущие продукты иногда используют буквенно-цифровые имена (например, Adobe Photoshop CS, CC) или год выпуска (Microsoft Office 2014). Формат ГГГГ-ММ-ДД упрощает сравнение релизов по старшинству.
Внутренние версии
У многих проектов есть маркетинговое имя и отдельная техническая версия, подчинённая строгим правилам. Например, Java SE 5.0 соответствует внутренней версии 1.5.0. Такие номера помогают быстро связаться с разработчиками при разборе ошибок.
Экзотические схемы
Иногда встречаются индивидуальные подходы. Так, Дональд Кнут нумерует версии системы типографики ΤΕΧ числами, приближающимися к π: 3.0, 3.1, 3.14 и т. п., что подчёркивает постепенное совершенствование.
Значение номера 1.0 и маркетинговые аспекты
Номер 1.0 часто считается вехой: для коммерческих продуктов это первый публичный релиз, хотя порой его считают ещё «сырым» и ожидают быстрого перехода к 1.2 или 2.0. В мире свободного ПО версия 1.0 сигнализирует о готовности программы для широкого использования непрофессионалами.
Маркетинг нередко влияет на нумерацию: номера могут менять, чтобы создать ощущение крупного обновления, или пропускать версии, чтобы уравняться с конкурентами. Существуют и суеверия — например, 13 иногда избегают или заменяют на "X3".
Алгоритмы определения старшинства версий
Часто нужно автоматически понять, какая из двух версий новее — это критично для обновлений и проверки совместимости. При десятичной дроби сравнивают целые части как числа, затем дробные как строки. Для многокомпонентных версий сравнение идёт покомпонентно до первого различия.
Простые приёмы, вроде лексикографического сравнения строк, дают ошибки: "10.0" может оказаться «меньше» чем "9.5". Из-за подобных проблем операционные системы иногда используют маскирующие внутренние номера, чтобы старые программы корректно определяли совместимость. В языках программирования есть специализированные функции, например version_compare() в PHP, которые решают эти задачи правильно.
Применение версионирования за пределами ПО
Идеи версионирования вышли за рамки программирования: их применяют в настольных ролевых играх (Dungeons & Dragons 3.5), в кинематографе ("Evangelion 2.0") и в терминах вроде «Веб 2.0» и «Веб 3.0», где числовая нумерация отражает смену парадигм.
