Tavaszi projektek verziónevezési sémája
1. Áttekintés
A kiadási verziók megnevezésekor gyakran használják a szemantikus verziót. Például ezek a szabályok olyan verzióformátumra érvényesek, mint a FŐBB.MINOR.REZÍCIÓ:
- FŐBB: Főbb jellemzők és lehetséges változások
- KISEBB: Visszafelé kompatibilis szolgáltatások
- FELÜLVIZSGÁLAT: Visszafelé kompatibilis javítások és fejlesztések
A Semantic Versioning mellett a projektek gyakran címkéket használnak az adott kiadás állapotának további tisztázására. Valójában ezen címkék használatával tippeket adunk a build életciklusáról vagy arról, hogy hol találhatók műtárgyak.
Ebben a rövid cikkben megvizsgáljuk a nagyobb tavaszi projektek által elfogadott verziónév-sémákat.
2. Tavaszi keret és tavaszi csomagtartó
A Semantic Versioning mellett láthatjuk, hogy a Spring Framework és a Spring Boot ezeket a címkéket használja:
- BUILD-SNAPSHOT
- M [szám]
- RC [szám]
- KIADÁS
A BUILD-SNAPSHOT a jelenlegi fejlesztői kiadás. A tavaszi csapat minden nap elkészíti ezt a műtárgyat, és a //maven.springframework.org/snapshot webhelyre telepíti.
A mérföldkő kiadás (M1, M2, M3,…) a kibocsátási folyamat jelentős szakaszát jelöli. A csapat elkészíti ezt a műtárgyat, amikor a fejlesztési iteráció befejeződik, és a //maven.springframework.org/milestone webhelyre telepíti.
A kiadásjelölt (RC1, RC2, RC3,…) az utolsó lépés a végleges kiadás elkészítése előtt. A kódváltozások minimalizálása érdekében ebben a szakaszban csak hibajavításokat szabad végrehajtani. A //maven.springframework.org/milestone mappára is telepítve van.
A kiadás legvégén a Tavaszi csapat kiad egy RELEASE-t. Következésképpen általában ez az egyetlen gyártásra kész műtárgy. Erre a kiadásra is hivatkozhatunk GA, az általános rendelkezésre állásért.
Ezek a címkék ábécé sorrendben vannak győződjön meg arról, hogy a build és a függőségkezelők helyesen állapítják meg, hogy a verzió frissebb-e egy másiknál. Például a Maven 2 tévesen tekintette az 1.0-SNAPSHOT-ot újabbnak, mint az 1.0-RELEASE. Maven 3 kijavította ezt a viselkedést. Ennek eredményeként furcsa viselkedést tapasztalhatunk, amikor a névadási sémánk nem optimális.
3. Esernyő projektek
Az esernyő projektek, mint például a Spring Cloud és a Spring Data, független, de kapcsolódó alprojektek. Az ezekkel az alprojektekkel való konfliktusok elkerülése érdekében egy ernyőprojekt más elnevezési sémát alkalmaz. Számozott változat helyett minden kiadó vonatnak külön neve van.
ABC-sorrendben a londoni metróállomások inspirálják a Spring Cloud kiadási neveket - kezdőknek, Angel, Brixton, Finchley, Greenwich és Hoxton.
A fent látható tavaszi címkék mellett meghatározza a Service Release címkét is (SR1, SR2…). Ha kritikus hibát találunk, akkor Service Release állítható elő.
Fontos felismerni, hogy a Spring Cloud kiadás csak egy adott Spring Boot verzióval kompatibilis. Hivatkozásként a Spring Cloud Project oldal tartalmazza a kompatibilitási táblázatot.
4. Következtetés
Amint a fentiekből kiderült, fontos a világos verzióelnevezési séma. Bár egyes kiadások, például a mérföldkövek vagy a kibocsátási jelöltek stabilak lehetnek, mindig gyártásra kész műtermékeket kell használnunk. Mi a névadási sémája? Milyen előnyei vannak ezzel szemben?