szemantikus verziózás (SemVer)

angolul: semantic versioning

haladóelterjedt

Olyan számozási szabály, amelyben a szoftver verziószámának három tagja elárulja, mekkora változást hoz a frissítés, és elronthatja-e a szoftverre épülő többi programot.

Érthetően

A szoftverek verziószáma sokszor három számból áll, például 2.4.1. A szemantikus verziózás azt mondja ki, hogy ezek a számok nem találomra nőnek: mindegyik helynek jelentése van. Az első a nagy változást jelzi, amely után a szoftverre épülő programok hibásan működhetnek (ezt hívják a fejlesztők törésnek). A második az új, de a régivel összeférő funkciót, a harmadik a hibajavítást jelöli.

Olyan ez, mint egy lakásfelújítás. Ha kicserélnek egy égőt, az hibajavítás: semmit sem kell másképp csinálnod. Ha beépítenek egy új konnektort, az új lehetőség, de a régiek ugyanúgy működnek. Ha viszont áthelyezik a falakat, a bútoraid már nem biztos, hogy beférnek a régi helyükre – ez a nagy verzióváltás.

Azért hasznos, mert a mai programok rengeteg mások által írt építőelemre támaszkodnak. A verziószámból a fejlesztő – vagy a helyette dolgozó kódoló agent – ránézésre látja, hogy egy frissítés nyugodtan feltehető, vagy előbb érdemes alaposan tesztelni.

Fontos különbség a marketingcélú számozáshoz képest: itt a szám nem azt üzeni, hogy mennyire nagy dobás az új kiadás, hanem azt, hogy mennyire kell óvatosnak lenned vele.

Hogyan működik

A verziószám három, ponttal elválasztott számból áll: FŐ.AL.JAVÍTÁS (angolul MAJOR.MINOR.PATCH), például 3.2.5.
Ha a készítők csak hibát javítanak, és minden más változatlan, az utolsó szám nő: 3.2.5-ből 3.2.6 lesz.
Ha új funkció kerül be úgy, hogy a régiek ugyanúgy működnek tovább, a középső szám nő, az utolsó pedig lenullázódik: 3.3.0.
Ha olyan változás történik, amely miatt a korábban rá épülő programok elromolhatnak, az első szám nő, a másik kettő lenullázódik: 4.0.0.
A 0-val kezdődő verziók (például 0.9.2) a kezdeti fejlesztési szakaszt jelzik, ahol még bármi bármikor megváltozhat; a kötőjeles toldalék (például 2.0.0-beta.1) pedig előzetes, még nem végleges kiadást jelöl.

Példa a mindennapokból

Egy webáruház programja egy mások által írt fizetési építőelemet használ, amelyből frissítés érkezik: 5.9.3-ról 6.0.0-ra vált. Ha a készítők a szemantikus verziózást követik, a fejlesztő ebből tudja, hogy nem apró javítás jön, hanem olyan változás, amely miatt a saját programját is át kell néznie, esetleg át kell írnia. Ha csak 5.9.4 érkezne, az hibajavítás volna, amelyet jó eséllyel gond nélkül feltehet. A telefonos alkalmazások számozására ez ritkán igaz, mert a legtöbbjük nem ezt a szabályt követi.

Kit érint

fejlesztőA verziószám alapján dönti el, melyik frissítést engedheti be automatikusan a projektjébe, és melyiknél kell számítania átírásra. → Kód

vállalkozó, vezetőEgy főverzióváltás a cég által használt szoftverben átállási költséget és tesztelési időt jelenthet, amit érdemes előre betervezni.

mindenkiA verziószám első tagjának változása gyakran nagyobb átalakítást jelez, de a hétköznapi alkalmazások és böngészők többsége nem ezt a szabályt követi, ezért a számukból csak óvatosan lehet következtetni.

Gyakori félreértés

TévhitA nagyobb verziószám mindig jobb, fejlettebb szoftvert jelent, a főverzióváltás pedig nagy újdonságokat.

ValójábanA szám nem a minőséget méri, hanem az összeférhetőséget: a főverzió akkor nő, ha valami a régi módon már nem működik. Ez lehet látványos megújulás, de akár egyetlen régi funkció eltávolítása is.

Korlátok és kockázatok

Ez ígéret, nem garancia: semmi sem kényszeríti ki, hogy a készítők helyesen számozzanak, így egy ártalmatlannak jelölt frissítés is okozhat hibát.
Sok ismert szoftver nem ezt a rendszert követi, hanem például dátum alapján vagy marketingszempontok szerint számoz, ezért nem minden háromtagú verziószám olvasható így.
A verziószám nem mond semmit a biztonságról vagy a minőségről: egy hibajavításnak jelölt kiadás is tartalmazhat új hibát vagy akár kártékony kódot.
Az automatikus frissítés – akár ember állítja be, akár egy agent végzi – a verziószámra hagyatkozva is csak tesztekkel együtt megbízható.

Hasonló, de nem ugyanaz

naptári verziózás (CalVer) – Ott a verziószám a kiadás dátumát mutatja (például 24.04), nem azt, hogy a változás mennyire töri meg a korábbi működést.
verziókezelés – A verziókezelés a kód minden módosítását nyilvántartó rendszer (például a Git), a szemantikus verziózás pedig csak a kiadások elnevezésének szabálya.
változásnapló – A változásnapló szövegesen felsorolja, mi változott, míg a verziószám ennek csak a súlyát jelzi egyetlen számhármassal.

Kapcsolódó fogalmak

Tágabb

szoftververziózás, szoftverfejlesztés, kiadáskezelés

Szűkebb

főverzió, alverzió, javítóverzió, előzetes kiadás

Rokon

verziókezelés, függőségkezelés, csomagkezelő, visszafelé kompatibilitás, API

Röviden a története

A háromtagú verziószámozás régi fejlesztői szokás volt, amelyet Tom Preston-Werner, a GitHub társalapítója foglalt írott szabályrendszerbe Semantic Versioning néven. A ma is érvényes 2.0.0-s változat 2013-ban jelent meg.

Hol tart most

2026 végén a nyílt forráskódú világ és a nagy csomagkezelők (például az npm és a Cargo) alapértelmezett számozási szokása. Az AI-eszközök, modellek és agentek körében viszont vegyes a kép: sokan dátum alapú vagy saját elnevezést használnak helyette.

Állapot: 2026. november

Más nevei

SemVer · semver · semantic versioning · szemantikus verziószámozás · szemantikus verziókezelés · szemantikai verziózás · MAJOR.MINOR.PATCH · Semantic Versioning 2.0.0

Források

A szócikk gépi szerkesztéssel készült és gépi szakmai lektoráláson ment át; a „hírekben” rész az Agent Age sztorijaiból automatikusan frissül.