Мудрый выбор разработчика
Есть много вещей, о которых заботится мудрый разработчик. Одним из них является семантическое управление версиями.
Прежде чем перейти к семантическому управлению версиями, давайте рассмотрим один пример:
Предположим, вы разрабатываете приложение с именем Building. При создании этого приложения вам необходимо интегрировать сторонний пакет под названием Crane. Когда вы устанавливали Crane в свое строительное приложение, его версия была 2.1.0. Через некоторое время вам понадобится еще один пакет с именем Truck, который имел версию 1.1.4. Среди этих 2 пакетов; Crane не соответствовал стандартам семантического управления версиями. И package Truck соответствующим образом следовал правилам семантического управления версиями.
Давайте ненадолго остановим этот пример и поймем, что такое семантическое управление версиями. В конце статьи мы продолжим этот пример и посмотрим, как выпуски Crane и Truck повлияют на ваше строительное приложение. Для удобства тему мы разбили на две части:
SemVer что это?
Семантическое управление версиями также называется SemVer для краткости обозначения. Это стандартизированный шаблон для обозначения версий любого приложения, пакета, библиотеки, API или любого другого продукта, где бы он ни применялся. (В дальнейшей статье SemVer расшифровывается как семантическое управление версиями)
MAJOR.MINOR.PATCHПример(ы) SemVer(s)
- 2.4.0 (Major: 2, Minor: 4, Patch: 0)
- 4.6.2 (Major: 4, Minor: 6, Patch: 2)Семантическая версия состоит в основном из 3 частей (она может быть больше в зависимости от того, на сколько уровней вы хотите ее углубить)
MAJOR: Он представляет собой основную версию приложения. Любое несовместимое изменение, модификация API или подобные изменения обрабатываются под этим номером.
MINOR: При добавлении новой функциональности в продукт вводится обратная совместимость. Любое улучшение (например, производительность, оптимизация и т.д.) может быть описано в этом разделе.
PATCH: Как следует из названия, он зарезервирован для исправления ошибок внутри системы/продукта. Обратите внимание, что эти исправления ошибок должны быть обратно совместимы.
Предположим, что в приложении у вас есть 15 зависимостей от сторонних пакетов. Если эти 15 пакетов не соответствуют надлежащей практике SemVer, то вы не будете знать, какой пакет обновлять и какое влияние это окажет на приложение. В какой-то момент вы окажетесь в аду зависимостей, где вам придется ждать, пока сторонние пакеты обновят свои версии, чтобы выпустить ваше приложение. Следуя правилам SemVer, мы можем легко и эффективно управлять зависимостями.
Соблюдение стандартов планирования выпуска и развертывания: о стабильности и сроке службы любого выпуска можно судить по его SemVer. Для конвейеров CI/CD также жизненно важную роль играет надлежащее управление версиями.
Правила
Существуют некоторые стандартные методы, которым следует следовать при использовании семантического управления версиями.
- MAJOR, MINOR, PATCH должны быть целыми числами (0,1,2...). Они не должны включать отрицательные целые числа или десятичные точки.
- Как только сведения о версии будут опубликованы для любого приложения, их не следует изменять. Значения версии могут быть изменены только в качестве нового выпуска.
- Сравнение 2 SemVer должно производиться слева направо в зависимости от возрастающего значения числа. Пример : 1.0.0 < 1.1.0 < 2.0.0 < 2.0.1
- Major версия 0 (0.x.y) предназначена для этапа разработки. Во время этого приложение не должно считаться стабильным.
Завершение нашего строительного приложения
Давайте завершим нашу статью, завершив пример. Мы создаем приложение под названием Building. И среди всего этого Crane не следовал за SemVer. Truck следовал за ним.
Когда вы планируете выпуск приложения Building в это время, версия Crane -> 2.1.3 и версия Truck -> 1.2.2. Таким образом, мы можем предсказать, что для Crane -> до версии 2.x.y и Truck -> до версии -> 1.p.q мы можем опубликовать ваше приложение, и никаких серьезных изменений не будет.
Но эта гарантия может быть обеспечена только package Truck, а не Crane. Причина в том, что Crane не соответствует стандартам SemVer. Таким образом, в следующем выпуске Crane -> версия 2.1.5 они могут внести некоторые важные изменения, о которых мы не знаем.
Если мы используем больше плохо спланированных пакетов, таких как Crane, это может привести к аду зависимостей и в конечном итоге к проблеме для приложения. Поэтому будьте осторожны при выборе пакетов.
Практика
Одной теории недостаточно. Мы рассмотрим практическое применение SemVer, разработав API MunchPay на основе узлов. Где мы проверим каждый аспект управления версиями и развертывания.
Вы можете ознакомится полной версией статьи и ознакомится с продолжением:
