streamalism.org

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?