Версионирование

semver (1).jpg

Semver

В разработке принято версионировать программное обеспечение.

Версия — это номер либо группа номеров (иногда с буквами или словами), которая обозначает какой-то конкретный этап разработки данного кода. Вот некоторые примеры: 0.0.2, 1.0.32, 1.33.

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

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

Современное версионирование кода основано на универсальном стандарте, который называется SEMVER (семантическое версионирование). По стандарту, версия представляет из себя три числа разделенных точками: 1.23.5. Каждое из этих чисел имеет собственно имя и предназначение:

  • Первое число (1 в примере выше) — мажорная версия. Меняется только в случае серьезных изменений, как правило, ломающих обратную совместимость
  • Второе число (23 в примере выше) — минорная версия. Не должна ломать обратную совместимость (в идеале). Меняется при добавлении новых возможностей.
  • Третье число (5) — патч. Гарантировано не должна менять обратную совместимость (к сожалению такое бывает). Меняется только при исправлении багов.

Для примера: версия 1.12.3 выше, чем версия 1.3.3, потому что 12 больше чем 3.

Соглашение о коммитах 1.0.0

Спецификация «Соглашение о коммитах» — простое соглашение о том, как нужно писать сообщения коммитов. Оно описывает простой набор правил для создания понятной истории коммитов, а также позволяет проще разрабатывать инструменты автоматизации, основанные на истории коммитов.

Сообщения должны быть следующей структуры:

<тип>[необязательный контекст]: <описание>

[необязательное тело]

[необязательная(ые) сноска(и)]
  • fix: коммит типа fix исправляет баг в вашем коде (соответствует PATCH в Cемантическом Версионировании).
  • feat: коммит типа feat добавляет новую функцию в ваш код (соответствует MINOR в Cемантическом Версионировании).
  • BREAKING CHANGE: коммит, который имеет сноску BREAKING CHANGE или коммит, заканчивающийся восклицательным знаком (!) после типа или контекста, вводящий изменение(я), нарушающие обратную совместимость (соответствует MAJOR в Cемантическом Версионировании)
  • Другие типы коммитов разрешены: build, chore, ci, docs, style, refactor, perf, test и другие.

Подробно про semver здесь -> semver.org
Соглашения о коммитах -> conventionalcommits.org

#basics
openImgPic