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

Семантичне версіонування (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, і жоден клієнт її не побачив.

Три числа

Від 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» — ні.

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

Наскільки ці моменти віддалені один від одного, залежить від команди. У Котокормі між мерджем і деплоєм кілька хвилин, реліз приходить у четвер, а флаг може тримати фічу невидимою ще тижнями після всіх трьох. У мобільній команді на git flow порядок інший: мердж у develop, реліз за кілька тижнів, потім перевірка в магазині застосунків, поступове розгортання на дедалі більшу частку користувачів і, нарешті, оновлення застосунку кожним користувачем. Чому моделі такі різні, пояснює стаття GitHub flow чи git flow.

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

Як відповісти, у якій версії виправлення #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 розбирає перший щотижневий реліз Котокорму і хотфікс наступного ранку, з практикою на номерах версій і нотатках до релізу, яку перевіряє ШІ. GitHub flow: малі гілки, швидкі мерджі пояснює різницю між «змерджено» і «викладено» та фіча-флаги, а Злиття: мердж-коміт, squash і rebase — squash-мердж і те, чому кожен pull request стає одним комітом у main. Усе це частина безкоштовного курсу Git і GitHub для продактів.