streamalism.org

1. Overzicht

Het is gebruikelijk om Semantic Versioning te gebruiken bij het benoemen van releaseversies. Deze regels zijn bijvoorbeeld van toepassing op een versieformaat zoals BELANGRIJKE BELANGRIJKSTE HERZIENING:

• MAJOR: Belangrijke kenmerken en mogelijke belangrijke veranderingen
• MINOR: Achterwaarts compatibele functies
• HERZIENING: Achterwaarts compatibele fixes en verbeteringen

Samen met Semantic Versioning gebruiken projecten vaak labels om de status van een bepaalde release verder te verduidelijken. Door deze labels te gebruiken, geven we zelfs hints over de build-levenscyclus of waar artefacten worden gepubliceerd.

In dit korte artikel zullen we de naamgevingsschema's voor versies bekijken die door grote Spring-projecten worden gebruikt.

2. Spring Framework en Spring Boot

Naast Semantic Versioning kunnen we zien dat Spring Framework en Spring Boot deze labels gebruiken:

• BOUW-SNAPSHOT
• M [aantal]
• RC [aantal]
• VRIJLATING

BUILD-SNAPSHOT is de huidige ontwikkelingsversie. Het Spring-team bouwt dit artefact elke dag en implementeert het op //maven.springframework.org/snapshot.

Een release van Milestone (M1, M2, M3,…) markeert een belangrijke fase in het releaseproces. Het team bouwt dit artefact wanneer een ontwikkelings-iteratie is voltooid en implementeert het op //maven.springframework.org/milestone.

Een Release Candidate (RC1, RC2, RC3,…) is de laatste stap voor het bouwen van de definitieve release. Om codewijzigingen te minimaliseren, zouden in dit stadium alleen bugfixes moeten plaatsvinden. Het wordt ook geïmplementeerd op //maven.springframework.org/milestone.

Helemaal aan het einde van het releaseproces produceert het Spring-team een ​​RELEASE. Bijgevolg is dit meestal het enige productieklare artefact. We kunnen ook naar deze release verwijzen als GA, voor algemene beschikbaarheid.

Deze labels zijn alfabetisch gerangschikt om ervoor te zorgen dat build- en afhankelijkheidsmanagers correct bepalen of een versie recenter is dan een andere. Maven 2 beschouwde bijvoorbeeld 1.0-SNAPSHOT ten onrechte als recenter dan 1.0-RELEASE. Maven 3 heeft dit probleem opgelost. Als gevolg hiervan kunnen we vreemd gedrag ervaren wanneer ons naamgevingsschema niet optimaal is.

3. Overkoepelende projecten

Overkoepelende projecten, zoals Spring Cloud en Spring Data, zijn projecten boven onafhankelijke maar gerelateerde subprojecten. Om conflicten met deze deelprojecten te voorkomen, hanteert een overkoepelend project een ander naamgevingsschema. In plaats van een genummerde versie heeft elke Release Train een speciale naam.

In alfabetische volgorde zijn de London Subway Stations de inspiratie voor de Spring Cloud-releasenamen - om te beginnen Angel, Brixton, Finchley, Greenwich en Hoxton.

Naast de hierboven getoonde Spring-labels, it definieert ook een Service Release-label (SR1, SR2 ...). Als we een kritieke bug vinden, kan een servicerelease worden geproduceerd.

Het is belangrijk om te beseffen dat een Spring Cloud-release alleen compatibel is met een specifieke Spring Boot-versie. Ter referentie: de Spring Cloud Project-pagina bevat de compatibiliteitstabel.

4. Conclusie

Zoals hierboven getoond, is het belangrijk om een ​​duidelijk schema voor de naamgeving van de versie te hebben. Hoewel sommige releases zoals Milestones of Release Candidates misschien stabiel zijn, moeten we altijd productieklare artefacten gebruiken. Wat is uw naamgevingsschema? Welke voordelen heeft het ten opzichte van deze?