ћерион Ќетворкс

6 минут

—емантическое управление верси€ми (или семвер) Ц это формальное соглашение дл€ определени€ номера версии новых выпусков программного обеспечени€. —тандарт помогает пользовател€м программного обеспечени€ пон€ть серьезность изменений в каждом новом дистрибутиве.

Semantic Versioning ѕроект, использующий семантическое управление верси€ми, объ€вл€ет основной номер версии (major), дополнительный номер версии (minor) и номер исправлени€ (patch) дл€ каждого выпуска. —трока версии 1.2.3 указывает на основную версию под номером 1, дополнительную версию под номером 2 и исправление под номером 3.

Ќомера версий такого формата широко используютс€ как программными пакетами, так и исполн€емыми файлами конечных пользователей, такими как приложени€ и игры. ќднако не каждый проект точно следует стандарту, установленному semver.org.

—пецификаци€ была создана дл€ решени€ проблем, вызванных несовместимостью методов управлени€ верси€ми между программными пакетами, используемыми в качестве зависимостей. ѕод Ђпакетомї и Ђзависимостьюї мы подразумеваем библиотеку кода, предназначенную дл€ использовани€ в другом программном проекте и распростран€емую диспетчером пакетов, таким как npm, composer или nuget. Ёто именно то применение семантического управлени€ верси€ми, которое мы рассматриваем в этой статье.


Major, Minor и Patch

¬ажно понимать значение трех задействованных компонентов. ¬месте они намечают путь разработки проекта и соотнос€т вли€ние каждого нового выпуска на конечных пользователей.

  • Major number (основной номер версии) Ц основной номер указывает на текущую версию общедоступного интерфейса пакета. ќн увеличиваетс€ каждый раз, когда вы вносите изменени€, которые требуют от существующих пользователей вашего пакета обновлени€ их собственной работы.
  • Minor number (дополнительный номер версии) Ц дополнительный номер указывает на текущую функциональную версию вашего программного обеспечени€. ќн увеличиваетс€ вс€кий раз, когда вы добавл€ете новую функцию, но не мен€ете интерфейс вашего пакета. ќн сообщает пользовател€м о том, что были внесены значительные изменени€, но пакет полностью совместимым с предыдущими верси€ми с предыдущим дополнительным номером.
  • Patch number (номер исправлени€) Ц номер исправлени€ увеличиваетс€ каждый раз, когда вы вносите какое-то незначительное изменение, которое не вли€ет на общедоступный интерфейс или общую функциональность вашего пакета. ≈го чаще всего используют дл€ исправлени€ ошибок. ѕотребители всегда должны иметь возможность не задумыва€сь установить последнюю версию исправлений.

—емантическа€ структура версии выпуска лучше всего моделируетс€ в виде дерева. Ќаверху у вас изменени€ общедоступного интерфейса, каждое из которых отображаетс€ на основном номере.  ажда€ основна€ верси€ имеет свой собственный набор дополнительных версий, в которые добавл€ютс€ новые функции без нарушени€ совместимости с предыдущими верси€ми. » наконец, дополнительные версии могут врем€ от времени отлаживатьс€ путем исправлени€ некоторых ошибок.


ќткуда начинать?

Ѕольшинство проектов должны начинатьс€ с версии 1.0.0. ¬ы публикуете свой первый общедоступный интерфейс и первоначальный неизмененный набор функций. » поскольку вам еще не приходилось вносить никаких исправлени€, то и верси€ исправлени€ Ц 0.

“еперь давайте посмотрим, что же происходит, когда вы вносите изменени€ в свой пакет. ѕосле вашего первоначального выпуска вы получаете отчет об ошибке от пользовател€.  огда вы выпустите исправление, то правильный номер версии уже будет 1.0.1. ≈сли бы вы затем выпустили еще одну версию с исправлением ошибок, то вы бы увеличили номер исправлени€ до 2, т.е. номер версии уже был бы 1.0.2.

“ем временем вы также работали над новой интересной функцией. Ёто совершенно необ€зательно, поэтому пользовател€м не нужно ничего делать дл€ обновлени€. ¬ы выпускаете эту версию как 1.1.0. Ц создана нова€ функциональна€ среда, но ее еще ни разу не исправл€ли.   сожалению, скоро приход€т отчеты об ошибках, и среди ваших пользователей начинает распростран€тьс€ верси€ 1.1.1.

Ќесколько мес€цев спуст€ вы решили провести реорганизацию кода всего проекта. Ќекоторые функции были удалены или теперь доступны через объединенный интерфейс. ≈сли вы выпустите эту работу, то люди, использующие текущую версию вашего пакета, должны будут внести серьезные изменени€ в свой проект. ѕришло врем€ опубликовать 2.0.0. в вашем репозитории пакетов.


ѕоддержание старых веток

”величение какого-либо номера в вашей строке версий не создает точку невозврата. ѕосле публикации 1.1.1 вы могли обнаружить ошибку, присутствующую в 1.0.2. »спользу€ ветки в вашей системе контрол€ версий, вы можете произвести исправлени€ в обеих верси€х. ¬ итоге вы получите 1.1.2 и 1.0.3.

“очно также вы можете поддерживать ветку 1.х вашего проекта, несмотр€ на выпуск 2.0.0. ћожет показатьс€ странным публиковать 1.1.2 после 2.0.1, но это вполне нормальна€ практика. —емантическое управление верси€ми не создает линейный посто€нно увеличивающийс€ номер версии; наоборот, оно предназначено дл€ использовани€ в качестве части модели разработки ветвлени€, которое использует простоту установки исправлений, предлагаемую системами управлени€ исходным кодом, такими как Git.

ќпубликованные версии должны быть неизмен€емыми. ѕосле того, как вы создали версию 2.4.3, вы не можете Ђобновитьї его, просто добавив дополнительный код в ту же строку версии. ¬ы должны присваивать новый номер версии каждому выпуску, чтобы пользователи всегда могли получить доступ к каждой конкретной версии вашего пакета.


ќбработка пакетов, наход€щихс€ в стадии разработки

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

¬ы можете этого избежать, рекламиру€ свой проект как 0.y.z. «начение 0 в качестве основной версии означает, что ваш пакет неустойчив. ќбычные правила в отношении совместимости с предыдущими верси€ми тут не примен€ютс€, поэтому вы можете выпускать новые версии, увеличива€ только дополнительный номер и номер исправлени€. Ёто значит, что вы можете использовать 1.0.0 дл€ обозначени€ первой Ђзавершеннойї версии вашего программного обеспечени€.

¬ы также можете добавить дополнительные Ђидентификаторыї в конец строки версии, использу€ дефис в качестве разделител€: 1.0.0-alpha.1. ¬ы можете использовать такой вариант дл€ того, чтобы четко обозначить альфа- и бета-версии. “очно также вы можете включить метаданные сборки, добавив символ +: 1.1.0-alpha.1+linux_x86.


«аключение

—огласованное использование семантического управлени€ верси€ми помогает пользовател€м быть уверенными в вашем проекте. ќни могут четко видеть, как развиваетс€ ваша кодова€ база и нужно ли им самим провести какую-то работу, чтобы идти в ногу со временем.

ќбъ€вление строки семантической версии необходимо при публикации в диспетчере наиболее попул€рных пакетов. “ем не менее, в конечном счете, вам решать, какие номера вы устанавливаете дл€ каждого нового выпуска. —облюдение стандарта четко сообщает о ваших намерени€х пользовател€м и сводит к минимуму риск непреднамеренного нарушени€ чужой работы.


—кидки 50% в Merion Academy

¬ыбрать курс