# SemVer, або семантичне версіонування простими словами: що означає v1.4.1 і коли зміна справді на сайті

> SemVer, або семантичне версіонування, для продактів: що означає MAJOR.MINOR.PATCH, теги й релізи на GitHub і чому «змерджено» й «на сайті» — різні моменти.

- Джерело: https://productovi.com/uk/blog/semantic-versioning-explained
- Автор: Sergey Bruh
- Опубліковано: 2026-10-02
- Теми: Релізи, теги та версії, GitHub flow, Мердж: merge commit, squash, rebase

Семантичне версіонування (SemVer) в одному реченні: **номер версії складається з трьох частин, MAJOR.MINOR.PATCH, і кожна частина каже, яка зміна відбулася. PATCH зростає для виправлень багів, MINOR — для нових можливостей, які нічого не ламають, MAJOR — для змін, що ламають щось, на що люди покладаються, а всі числа праворуч від того, що зросло, обнуляються.** Тож `v1.4.1` читається як «реліз з новими можливостями 1.4.0 плюс одна порція виправлень». Чого номер версії не каже, то це чи бачить зміну клієнт. Для продакт-менеджера саме ця половина теми корисніша: «змерджено», «викладено», «випущено» і «видно всім клієнтам» — чотири різні моменти, і версія стоїть десь посередині.

## Приклад: «У якій версії виправлення?»

Підтримка Котокорму, інтернет-магазину кормів для тварин, хоче відповідати клієнтам про баг із кнопкою оформлення замовлення: «виправлено у версії така-то». Виправлення, pull request #134, змерджили в середу о 9:40, а Котокорм автоматично викладає кожен мердж, тож о 9:44 воно вже було на сайті.

Чесна відповідь у ту середу: «у жодній». Команда мала кілька старих тегів, поставлених вручну для великих запусків, останній з них `v1.3.0`, і відтоді нічого. У четвер наступного тижня команда завела звичку: щочетверга поточна `main`, яка вже й так на сайті, отримує тег версії й нотатки до релізу. Перший такий реліз, `v1.4.0`, перелічив п'ять змерджених pull requests, серед них і #134.

У тому самому релізі була й основа для програми лояльності. Цей код теж виклали, але сховали за фіча-флагом, тож жоден клієнт програми не бачив. Наступного ранку підтримка переслала повідомлення клієнтів, які знайшли в меню посилання на приховану програму, і воно вело на порожню сторінку. Виправлення у два рядки вийшло як `v1.4.1`, PATCH-реліз, бо після `v1.4.0` більше нічого не мерджили.

Тож у якій версії виправлення кнопки? «Виправлено у 1.4.0 і в усіх наступних версіях». Номер версії воно отримало, коли вже понад тиждень працювало на сайті. А програму лояльності «випустили» у `v1.4.0`, і жоден клієнт її не побачив.

## MAJOR, MINOR, PATCH: три числа

| Частина | Зростає, коли                                    | Приклади з продукту                                                            |
| ------- | ------------------------------------------------ | ------------------------------------------------------------------------------ |
| PATCH   | Лише виправлення, нічого нового                  | Хибне посилання у футері, помилка в тексті кошика, збій під час входу          |
| MINOR   | Нові можливості, а все інше працює як раніше     | Записка до подарунка в кошику, новий спосіб доставки, програма лояльності      |
| MAJOR   | Перестає працювати щось, на що люди покладаються | Прибрані поля API, змінені адреси сторінок, новий формат імпорту для партнерів |

Від `1.3.0`:

- виправлення дає `1.3.1`;
- нова можливість дає `1.4.0` (PATCH обнуляється);
- несумісна зміна дає `2.0.0` (MINOR і PATCH обнуляються).

Кілька деталей, на яких часто спотикаються:

- **Числа, а не абетка.** Кожну частину порівнюють як ціле число, зліва направо. `1.4.10` новіша за `1.4.9`, а `1.10.0` новіша за `1.9.0`. Список тегів на GitHub не завжди сортує їх саме так (станом на 2026 рік), тож довіряйте числам, а не порядку на сторінці.
- **Пре-релізи.** Суфікс на кшталт `2.0.0-beta.1` позначає тестову версію. Вона йде перед `2.0.0` і після всіх `1.x`.
- **Нульова версія.** `0.y.z` означає початкову розробку: будь-що може змінитися будь-коли, і правила вище по-справжньому діють лише від `1.0.0`.
- **Літера `v`.** `v1.4.1` — поширена звичка для назв тегів. Сама версія — `1.4.1`.

## Чи підходить семантичне версіонування сайту або застосунку?

Офіційні правила писали для програм, від яких залежать інші програми: бібліотек та API. Там «несумісна зміна» має точне значення: код, який працював з версією 1, перестає працювати з версією 2, доки його не змінять. Розробник, який бачить нову MAJOR-версію, знає, що перед оновленням треба прочитати нотатки.

У сайту чи застосунку для звичайних клієнтів такого контракту немає, тож команда має сама вирішити, що для неї означає «ламає». Правило Котокорму — один із прикладів: MAJOR, якщо перестають працювати старі посилання, збережені кошики чи інтеграції з партнерами; MINOR для нових можливостей; PATCH лише для виправлень. Запишіть таке правило для своєї команди один раз, і суперечки про версії стануть короткими.

Не кожен продукт користується семантичним версіонуванням. Деякі команди нумерують версії за датою, як-от `2026.11`, а багато мобільних застосунків показують «маркетингову версію» за власною логікою. Обидва варіанти нормальні, якщо команда послідовно тримається однієї схеми.

## Теги, релізи й нотатки до релізу на GitHub

**Тег** — це постійна назва для одного коміту. Гілка рухається вперед із кожним новим комітом, а тег лишається там, де його поставили. Тому версії й роблять тегами. Технічно тег можна видалити й створити знову, але опублікований тег ніколи не переносять: люди й інструменти розраховують, що `v1.4.0` назавжди означає той самий код.

**Реліз** на GitHub — це сторінка на основі тегу з нотатками й необов'язковими файлами. Станом на 2026 рік у розділі `Releases` («релізи») кнопка `Draft a new release` («створити чернетку релізу») відкриває форму, де можна обрати чи створити тег, вказати попередній тег і натиснути `Generate release notes` («згенерувати нотатки до релізу»). GitHub перелічить усі pull requests, змерджені після того тегу, з назвами й авторами. Важливі два прапорці: `Set as a pre-release` («позначити як пре-реліз») для тестових версій і `Set as the latest release` («позначити як останній реліз»), після якого сторінка отримує позначку `Latest`. `Latest` означає найновіший повноцінний реліз, а не «щойно викладено».

Згенерований список — це сировина, написана для інженерів. **Changelog** — людська версія: що змінилося, словами, які зрозуміють клієнти й підтримка. Зручний формат: короткий розділ «Для клієнтів і підтримки» зверху, простими словами, а під ним згенерований список. Саме тут варто перевірити, що приховане лишається прихованим: нічого з-за флагу не анонсують.

Добрі назви pull requests тут окупаються вдруге. «Fix checkout button after cart edits» стає зрозумілим рядком у нотатках, а «Daniel's branch» — ні.

## Змерджено, викладено, випущено, видно

| Момент    | Що означає                                              | Де перевірити                                                        |
| --------- | ------------------------------------------------------- | -------------------------------------------------------------------- |
| Змерджено | Зміну прийнято в гілку                                  | Pull request позначено «Merged» і вказано гілку                      |
| Викладено | Цей код працює на робочих серверах                      | Завдання деплою або `Deployments` («деплої») на сторінці репозиторію |
| Випущено  | Версія, яка його містить, має назву й нотатки           | Сторінка `Releases`, теги, що містять коміт                          |
| Видно     | Клієнти справді бачать зміну й можуть нею користуватися | Налаштування фіча-флагів, стан поступового розгортання, сам продукт  |

Наскільки ці моменти віддалені один від одного, залежить від команди. У Котокормі між мерджем і деплоєм кілька хвилин, реліз приходить у четвер, а флаг може тримати фічу невидимою ще тижнями після всіх трьох. У мобільній команді на git flow порядок інший: мердж у `develop`, реліз за кілька тижнів, потім перевірка в магазині застосунків, поступове розгортання на дедалі більшу частку користувачів і, нарешті, оновлення застосунку кожним користувачем. Чому моделі такі різні, пояснює стаття [GitHub flow чи git flow](/uk/blog/github-flow-vs-git-flow).

![Виправлення кнопки змерджили, виклали й показали клієнтам за кілька хвилин, а версію воно отримало через тиждень; основу програми лояльності виклали й випустили, але вона лишалася прихованою за фіча-флагом](/blog/semantic-versioning-explained/diagram-uk.png)

Коли вас питають «це вже працює?», спершу з'ясуйте, про який із чотирьох моментів ідеться. Маркетинг зазвичай має на увазі «видно всім клієнтам», підтримка — «виправлено для клієнта, який зараз на лінії».

## Як відповісти, у якій версії виправлення #N

1. **Відкрийте pull request.** Якщо його не змерджено, жодна версія виправлення не містить.
2. **Знайдіть його коміт у `main`.** За squash-мерджу кожен pull request стає одним комітом у `main`, назва якого закінчується на `(#N)`, тож сторінка pull request веде просто на нього.
3. **Перевірте теги.** Станом на 2026 рік сторінка коміту показує теги, які його містять. Найстаріший із них — перша версія з виправленням.
4. **Або порівняйте дві версії.** Порівняння на кшталт `v1.4.0...v1.4.1` показує, що саме додалося між двома тегами.
5. **Або прочитайте нотатки до релізів по порядку.** Знайдіть першу версію, у нотатках якої згадано виправлення. Кожна наступна версія теж його містить, якщо в пізніших нотатках не сказано, що його відкотили.

Відповідь, яку підтримка може переслати клієнту: «Виправлено у 1.4.0 і в усіх наступних версіях».

## Типові помилки

**Вважати нотатки до релізу повним вмістом версії.** Нотатки перелічують лише нове від попередньої версії. У нотатках до `v1.4.1` виправлення кнопки оформлення немає, а у версії воно є.

**Анонсувати все, що є в релізі.** Фіча може входити в реліз і бути невидимою за флагом. Перевірте флаги, перш ніж писати анонс.

**Вважати «Latest» чи «опубліковано» тим самим, що «викладено».** У командах, які викладають кожен мердж, код був на сайті ще до появи релізу. В інших командах публікація релізу запускає деплой. З'ясуйте, як у вас.

**Називати реліз із новою фічею патчем.** Якщо від останнього тегу пролізло щось нове, чесно підняти MINOR, навіть коли реліз робили заради виправлення.

**Переносити тег.** Якщо `v1.4.0` раптом вказує на інший код, ламаються всі розмови й інструменти, які на нього посилалися. Замість цього випустіть нову версію.

## Що зробити цього тижня

1. Відкрийте сторінки `Releases` і `Tags` («теги») свого продукту. Яка остання версія і коли вона вийшла?
2. Спитайте, як команда обирає між MAJOR, MINOR і PATCH, і запишіть правило, якщо його ще ніхто не записав.
3. Візьміть одне важливе для вас виправлення й знайдіть першу версію, яка його містить.
4. Запропонуйте написати частину наступних нотаток до релізу простими словами.

## Головне

- MAJOR.MINOR.PATCH: несумісні зміни, нові можливості, виправлення. Числа праворуч обнуляються.
- Порівнюйте версії як числа: `1.4.10` новіша за `1.4.9`.
- Тег назавжди називає один коміт; реліз на GitHub — це сторінка з нотатками на основі тегу.
- «Змерджено», «викладено», «випущено» і «видно» можуть бути чотирма різними моментами.
- Версія містить усе, що було до неї на тій самій лінії, а не лише те, що є в її нотатках.

## FAQ

### Що означає v1.4.1?

MAJOR-версія 1, MINOR-версія 4 і перший патч поверх `1.4.0`. За правилами семантичного версіонування `1.4.1` не має містити нічого нового порівняно з `1.4.0`, лише виправлення.

### Що означає версія, яка починається з нуля?

Що продукт чи бібліотека в стані початкової розробки, і будь-що може змінитися без нової MAJOR-версії. Багато команд переходять на `1.0.0`, коли готові обіцяти стабільність.

### Чи викладає код публікація релізу на GitHub?

Сама по собі ні. Реліз — це сторінка з нотатками на основі тегу. Деякі команди налаштовують автоматизацію, щоб публікація релізу запускала деплой; інші, як-от команди, що викладають кожен мердж, публікують реліз, коли код уже на сайті.

### Чим changelog відрізняється від нотаток до релізу?

Часто це одне й те саме в різних місцях. Нотатки до релізу живуть на сторінці кожного релізу, а changelog збирає зміни всіх версій в одному місці, іноді у файлі `CHANGELOG.md`. В обох випадках пишіть для людей, а не для Git.

## Спробуйте на практиці

Урок [Релізи й версії: теги, SemVer, changelog](/uk/courses/git-for-product/releases-and-versions/theory) розбирає перший щотижневий реліз Котокорму і хотфікс наступного ранку, з практикою на номерах версій і нотатках до релізу, яку перевіряє ШІ. [GitHub flow: малі гілки, швидкі мерджі](/uk/courses/git-for-product/github-flow/theory) пояснює різницю між «змерджено» і «викладено» та фіча-флаги, а [Злиття: мердж-коміт, squash і rebase](/uk/courses/git-for-product/merging/theory) — squash-мердж і те, чому кожен pull request стає одним комітом у `main`. Усе це частина безкоштовного курсу [Git і GitHub для продактів](/uk/courses/git-for-product).

## Пов’язані уроки

- [Релізи на GitHub і версії: теги, SemVer, changelog](https://productovi.com/uk/courses/git-for-product/releases-and-versions.md)
- [GitHub flow: малі гілки, швидкі мерджі](https://productovi.com/uk/courses/git-for-product/github-flow.md)
- [Злиття (git merge): мердж-коміт, squash і rebase на GitHub](https://productovi.com/uk/courses/git-for-product/merging.md)