Kiemelt kép

Mi az a szemantikus verziózás (SemVer)?

A szemantikus verziózás/verziószámozás (angolul Semantic Versioning, röviden SemVer) egy verziózási módszer, amely néhány éve azzal a céllal jött létre, hogy egységesítse a verziózási szokásokat.

Aki dolgozott már függőségekkel (tehát gyakorlatilag minden fejlesztő), az pontosan tudja, hogy idővel rémálommá tud válni a szoftver függőségeinek (dependency-jeinek) folyamatos naprakészen tartása. De szerencsére ma már a legtöbb programozási nyelv, keretrendszer, programkönyvtár, egyéb publikus API áttért a szemantikus verziószámozásra, így talán már nem is olyan vészes a helyzet.

De mit is jelent ez az egész pontosan? 

A szemantikus verziószám három inkrementális, kezdő nullák nélküli számból áll elő: 

A képen látható módon a MAJOR.MINOR.PATCH alakban írható le minden verzió, ahol egyik elem sem hagyható el és szigorú szabályok vonatkoznak arra, hogy mikor melyiket növelhetjük.

  • A MAJOR, vagy magyarul a főverzió abban az esetben növekszik, ha egy visszafelé nem kompatibilis API-frissítést adunk ki. 
  • A MINOR, vagyis az alverziószám új funkciók, módosítások bevezetésével növekszik. De fontos, hogy ezek a módosítások visszafelé kompatibilisek legyenek.
  • A PATCH verziószám pedig a nevéből is látható módon javításokra/bugfixekre lett kitalálva. Természetesen a visszafelé kompatibilitás itt is szigorú szabály. Tágabb értelmezésben PATCH verziót szoktak növelni jelentéktelen módosításoknál is.

Ennek az egésznek az a nem titkolt célja, hogy amikor új frissítés válik elérhetővé, akkor már a verziószámból egyértelmű legyen, hogy az milyen mértékben érintheti a meglévő kódunkat. A dependency-kezelő rendszereknek pedig meg tudjuk adni, hogy a főverzió vagy az alverzió a fix, patch verzió pedig bátran jöhet egy-egy NPM/Composer/Maven/Gradle/stb. függőség frissítés során. 

A SemVer nem írja le kötelezően az előzetes kiadások verziózására vonatkozó szabályokat. Például, ha mi szeretnénk egy verzió kiadása előtt alpha, beta, rc verziókat is közzétenni, akkor ilyen esetben használhatjuk az 1.5.0-alpha vagy az 1.5.0-alpha.1 alakot. De akár teljesen el is hagyhatjuk ezeket a jelöléseket.

Továbbá használhatunk ún. meta információkat is. Ilyen esetben a teljes verzió így néz ki: 1.5.0-alpha.1+20200226 vagy 2.2.1-rc+003.

Nézzük meg a gyakorlatban!

Van egy publikus API-nk (pl. egy HTTP kliens könyvtárat fejlesztünk), amely a SemVer szerint 0.1.0-ról indul, elkezdünk rajta dolgozni majd elérünk az első publikus verzióig. Ilyen esetben lépünk az 1.0.0 főverzióra

A publikus használat során kapunk hibajelentéseket (nem működik megfelelően a POST és a GET kérések elküldése, valakinek eszébe jutott olyanra is használni, ami nem lett alaposan letesztelve), a javításokkal a patch verziót növeljük: 1.0.1, 1.0.2, stb. 

Nagyon menő, hogy pár sorral tudunk GET és POST kéréseket küldeni és válaszokat fogadni vele, de igény merült fel a DELETE metódus használatára is, így kiadjuk az új verziót 1.1.0-ként, a patch így 0 lesz. 

Tehát mindent IS tudunk vele csinálni, csak valahogy totál elfelejtettük a HTTPS-ek kezelését is, pedig a Google már egy ideje figyelmezteti a webfejlesztőket, hogy keményen lesúlyt az SSL nélküli oldalakra… De ehhez újra kell gondolni az egészet, ami magával von egy csomó API-breaking módosítást. Ki kell adni a 2.0.0-t, így mindenki, aki használja, tudja majd, hogy ezt a függőséget már nem lehet minden gond nélkül frissíteni.

Összefoglalva

A SemVer nem egy kötelező verziózási rendszer, de ma már elkerülhetetlen, hogy valamilyen módon ne fussunk bele és érdemes belátni, hogy a saját és mások munkáját is megkönnyítjük vele, ha egy logikus szabványt követünk mi is.

Ha hasznos volt ez a poszt, kérlek oszd meg másokkal is. Köszönöm!


Ha nem szeretnél lemaradni a hasonló posztokról, kövesd a blog Facebook oldalát!