A szemantikus verziózás hivatalos megállapodás az új szoftverkiadások verziószámának meghatározására. A szabvány segít a szoftverfelhasználóknak megérteni az egyes új disztribúciók változásainak súlyosságát.
A szemantikus verziót alkalmazó projekt a Jelentősebb, Kiskorú és Tapasz szám minden kiadáshoz. A verzió karakterlánc 1.2.3 jelzi a Jelentősebb 1. változata, a kiskorú verziója és a javítás száma 3.
Az ezt a formátumot használó verziószámokat mind a szoftvercsomagok, mind a végfelhasználói futtatható fájlok, például alkalmazások és játékok széles körben használják. Nem minden projekt pontosan követi az általuk meghatározott szabványt semver.org.
A specifikációt annak a problémának a kezelésére hozták létre, amelyet a függőségként használt szoftvercsomagok következetlen verziókezelési gyakorlata okoz. A „csomag” és a „függőség” alatt egy olyan kódkönyvtárra utalunk, amelyet egy másik szoftverprojektben kívánnak használni, és amelyet egy csomagkezelő terjeszt, például npm, composer vagy nuget. Ez a szemantikus verziózás alkalmazása, amelyet ebben a cikkben mérlegelünk.
Őrnagy, kiskorú és javítás
Fontos megérteni a három érintett elem jelentését. Együtt ábrázolják a projekt fejlesztési útját, és összehasonlítják az egyes új kiadások végfelhasználói hatásait.
- Major szám – A fő szám a csomag nyilvános felületének aktuális verzióját jelzi. Ezt minden alkalommal növelni kell, amikor olyan változtatást hajt végre, amely a csomag meglévő felhasználóinak saját munkájának frissítését igényli.
- Kisebb szám – A kisebb szám a szoftver aktuális funkcionális kiadását írja le. Ez növekszik, ha új funkciót ad hozzá, de a csomag kezelőfelületét más módon nem változtatja meg. Közli a felhasználókkal, hogy jelentős változás történt, de a csomag teljesen visszafelé kompatibilis marad az előző kisebb számmal.
- Javítás száma – A javítás száma minden alkalommal növekszik, amikor kisebb változtatásokat hajt végre, amelyek nem befolyásolják a csomag nyilvános felületét vagy általános működését. Ezt leggyakrabban hibajavításokra használják. A fogyasztóknak mindig habozás nélkül képesnek kell lenniük a legfrissebb patch kiadás frissítésére.
A szemantikus verziójú kiadási struktúra legjobban faként modellezhető. Legfelül a nyilvános felület változásai történnek, amelyek mindegyike új fő számot eredményez. Minden nagyobb sorozatnak megvan a saját kisebb kiadása, ahol az új funkcionalitás visszafelé kompatibilis módon kerül hozzáadásra. Végül a kisebb kiadások időnként hibajavító javításokat kaphatnak.
Hol kezdjem?
A legtöbb projektnek használnia kell 1.0.0 mint kezdeti változatuk. Ön közzéteszi az első nyilvános felületét és a kezdeti változatlan funkcionalitáskészletet. Még nem kellett javítást létrehoznia, tehát a javítás verziója az 0.
Most nézzük meg, mi történik, amikor módosítja a csomagját. Az első kiadás után hibajelentést kap a felhasználótól. Amikor kiadja a javítást, a helyes verziószám lesz 1.0.1. Ha egy újabb hibajavító kiadást hozna létre, akkor a patch számát felemelné 1.0.2.
Időközben egy izgalmas új funkción is dolgozott. Teljesen választható, így a felhasználóknak semmit sem kell tenniük a frissítéshez. Ezt kiadod 1.1.0 – új funkcionális sorozat jött létre, amelyet még nem kellett foltoznia. Sajnos a hibajelentések hamarosan megjelennek és így 1.1.1 kiszorul a felhasználók számára.
Néhány hónap múlva úgy döntött, hogy átalakítja az egész projektet. Az Ön által korábban kínált funkciók egy részét eltávolítottuk, vagy most egy összevont felületen keresztül érjük el. Ha kiadta ezt a művet, a csomagjának jelenlegi verzióját használó embereknek jelentős változtatásokat kell végrehajtaniuk a projektjükön belül. Ideje publikálnod 2.0.0 a csomagtárába.
Az idősebb ágak fenntartása
Ha egy számot elüt a verzió karaktersorozatán belül, az nem hoz létre pontot, ahol nincs visszatérés. Közzététel után 1.1.1, felfedezhet egy hibát, amely szintén jelen volt 1.0.2. Az ágak használatával a forrásvezérlő rendszerben mindkét verziósorra alkalmazhatja a javítást. Végül kiadnád 1.1.2 és 1.0.3.
Hasonlóképpen érdemes fenntartani a 1.x annak ellenére, hogy kiadták 2.0.0. Furcsa érzés lehet publikálni 1.1.2 után 2.0.1 de ez teljesen elfogadható gyakorlat. A szemantikus változat nem hoz létre lineáris, mindig növekvő verziószámot; ehelyett egy elágazó fejlesztési modell részeként kívánják felhasználni, amely kihasználja a forrásvezérlő rendszerek, például a Git által kínált javítás egyszerűségét.
A közzétett változatoknak változhatatlannak kell lenniük. Miután létrehozott egy kiadást, például 2.4.3, nem tudja „frissíteni”, ha egyszerűen további kódot nyom meg ugyanazon verzió karaktersorozat alatt. Minden verzióhoz új verziószámot kell rendelnie, így a felhasználók mindig hozzáférhetnek a csomag minden egyes verziójához.
Kiadás előtti csomagok kezelése
Rendszerint mindig a projekt fő verzióját ütközteti, ha visszafelé összeférhetetlen változás kerül bevezetésre. Amikor az indítás előtti állapotban van, a kódbázisa nagyon gyorsan fejlődhet, aminek eredményeként számos nagy verzió jelenik meg.
Ezt elkerülheti úgy, hogy a projektet a 0.y.z mindenekelőtt. Örökbefogadás 0 mivel fő verziója azt jelzi, hogy a csomagja instabil. A visszafelé inkompatibilis változásokra vonatkozó szokásos szabályok már nem érvényesek, így új kiadásokat csak a kisebb és a javítás számának növelésével tehet közzé. Ez azt jelenti, hogy továbbra is használhatja 1.0.0 a szoftver első „kész” verziójának felcímkézése.
A verziósztring végéhez további „azonosítókat” is fűzhet, elválasztóként kötőjelet használva: 1.0.0-alpha.1. Ezzel egyértelműen jelölheti az alfa és a béta változatokat. Hasonlóképpen beépítheti az összeállítási metaadatokat is a + karakter: 1.1.0-alpha.1+linux_x86.
Következtetés
A szemantikus verziók következetes használata elősegíti a felhasználók bizalmát a projektben. Világosan láthatják, hogyan fejlődik a kódbázisod, és hogy maguknak kell-e elvégezniük a munkát a naprakészség érdekében.
A szemantikus verzióváltó karakterlánc hirdetése elengedhetetlen, ha a legnépszerűbb csomagkezelőknek publikál. Mindazonáltal végső soron az Ön döntése, hogy mely számokat fogja megütni minden egyes új kiadáshoz. Ragaszkodni a szabvány világosan közli szándékait a közösséggel, és minimalizálja annak kockázatát, hogy önkéntelenül megtörje valaki más munkáját.
