Авторский проект IT-специалиста Олега Барабанова Персональные публикации на тему IT и не только…

SemVer - спецификация, призванная помочь регламентировать порядок нумерации версий ваших релизов

Каждый разработчик, впервые выпуская какой-либо софт, сталкивается с задачей корректной нумерации версий своих релизов и с решением этой задачи призваны помочь уже существующие стандарты и спецификации.

SemVer Logo

В этой статье я хочу уделить внимание одной широко используемой спецификации SemVer (Семантическое Версионирование), в которой четко регламентированы правила нумерации версий. Спецификация была впервые опубликована в 2011 году и на момент написание статьи имеет версию 2.0.0 (версионирование этого документа соответствует самой спецификации!).

Краткая суть SemVer

SemVer представляет собой спецификацию четко регламентирующую правила нумерации версий. На сайте semver.org представлен текст спецификации с переводом на множество языков, а с развитием проекта вы можете ознакомиться в репозитории https://github.com/semver/semver.

Если совсем кратко, то схему версионирования можно совокупно представить в виде такой схемы:

{major}.{minor}.{patch}-{tag}+{buildmetadata}

Рассмотрим отдельные части этой схемы:

При каждом выпуске, увеличивается только одно число, а все последующие числа должны обнулиться, например, 2.3.42.4.03.0.0. Поскольку в эту статью я никак не планировал выносить все содержимое спецификации, то с остальными подробностями вы можете ознакомиться на официальном сайте semver.org.

Преимущества SemVer

Спецификация SemVer вполне покрывает потребности большинства проектов за счет своих преимуществ в виде простоты, краткости, информативности, гибкости и вследствие всего этого - популярности.

Краткость и простота

Одним из главных преимуществ Semver является то, что он очень простой, а полный текст спецификации можно прочитать и детально разобрать менее чем за час, а бегло с основными правилами SemVer вообще можно ознакомиться минут за 5.

Информативность и гибкость версионирования

При том, что спецификация простая, она очень информативна. Чтобы понять суть информативности в версионировании, давайте рассмотрим пример примитивного версионирования, через простое увеличения номера версии, например "версия 5". Как видно номер версии не говорит абсолютно ничего, кроме того, что это не самая старая версия. Кто делал хоть раз дипломную работу, курсовую или даже реферат, наверное наверное сталкивались с веселым именованием вида "Дипломная_работа_версия1", "Дипломная_работа_версия2", "Дипломная_работа_финальная_версия", "Дипломная_работа_финальная_версия_2" и т.д.

В SemVer, встретив версию 5.0.0, по номеру вы сразу сможете понять, что эта версия с весомыми изменениями, но к которой еще не вышло никаких патчей. При этом впоследствии обновив до версии 5.3.6, вы вправе ожидать обратную совместимость. А вот к обновлению до версии 6.x.x нужно относиться с большой осторожностью, поскольку изменение МАЖОРНОЙ версии, явно дает понять, что в API появились серьезные изменения, которые могут быть несовместимы с прошлой версией.

Широкое распространение и стандартизация

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

Регламентированный порядок релизов

Одно из важных, хоть и не очевидных преимуществ SemVer состоит в побуждении разработчиков более обдуманно и дисциплинированно подходить к самим релизам.

Возьмем за пример версию продукта 2.3.4 и представим ситуацию, что у вас есть какое-то серьезное изменение в вашем API (меняет первое число), а также несколько несвязанных с этим доработок и патчей (второе и третье число в версии). В каком порядке их выкатить? Рассмотрим несколько вариантов:

  1. Выкатить все изменения сразу в версию 3.0.0 (2.3.43.0.0). В таком случае пользователи старой версии 2.x.x возможно не смогут воспользоваться вашими важными патчами и парой новых доработок, т.к. вместе с ними в новой версии идут и серьезные изменения в API.
  2. Выкатить вначале версию 3.0.0 с серьезными изменениями, а потом внести отдельно доработки и патчи в версию 3.1.0 (2.3.43.0.03.1.0). В таком случае это уже будет как минимум версия 3.1.0. Как и в первом случае, пользователи версии 2.x.x возможно не смогут обновиться до новой версии но зато при частых релизах, будет явна по номерам, история изменений: 2.3.43.0.03.1.0.
  3. Выкатить вначале единую версию с патчами и доработками 2.4.0, а затем версию с изменениями в API (2.3.42.4.03.0.0). Это оптимальный вариант при нечастых релизах, поскольку пользователи еще актуальной версии 2.3.4, обновившись до версии 2.4.0 спокойно смогут воспользоваться вашими дополнениями и патчами.
  4. Выкатить вначале патч 2.3.5, потом версию с доработками 2.4.0 и затем уже отдельно версию с изменениями API 3.0.0 (итого 2.3.42.3.52.4.03.0.0). Фактически это является расширением прошлого варианта, но с отдельным патчем. Такой вариант при частых релизах очень информативен, поскольку позволяет более подробно видеть историю изменений. Также этот вариант очень полезен в случае работы с программным обеспечением имеющим долгосрочную поддержку (LTS — long-term support), где патч (2.3.5) очень востребован, а вот новым доработкам (2.4.0) пока еще доверия нет.

Нюансы универсальности SemVer

Semver является вполне универсальной спецификацией, которая подходит для большинства и по причине этой универсальности, он не может подходить абсолютно всем.

Нет смысла переходить на SemVer, если ваш код уже давно и успешно использует какие-то другие правила версионирования. Например, посмотрите на историю изменений SQLite, у которого нумерация версий крайне схожа с SemVer, но SemVer официально появился в 2011 году, а SQLite разрабатывается аж с 2000 года.

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

Заключение

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

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