streamalism.org

1. Oversigt

Det er almindeligt at bruge Semantic Versioning, når der navngives udgivelsesversioner. For eksempel gælder disse regler for et versionformat som f.eks STOR.MINOR.REVISION:

• STØRRELSE: Vigtige funktioner og potentielle brydende ændringer
• MINDER: bagudkompatible funktioner
• REVISION: Bagudkompatible rettelser og forbedringer

Sammen med semantisk versionering bruger projekter ofte etiketter til yderligere at afklare tilstanden for en bestemt udgivelse. Faktisk ved at bruge disse etiketter giver vi tip om bygningens livscyklus, eller hvor artefakter offentliggøres.

I denne hurtige artikel undersøger vi de version-navngivningsordninger, der er vedtaget af større forårsprojekter.

2. Spring Framework og Spring Boot

Ud over semantisk versionering kan vi se, at Spring Framework og Spring Boot bruger disse etiketter:

• BUILD-SNAPSHOT
• M [nummer]
• RC [nummer]
• FRIGØRE

BUILD-SNAPSHOT er den nuværende udviklingsudgivelse. Spring-teamet bygger denne artefakt hver dag og distribuerer den til //maven.springframework.org/snapshot.

En Milestone-frigivelse (M1, M2, M3,…) markerer et vigtigt trin i frigivelsesprocessen. Holdet bygger denne artefakt, når en iteration af udviklingen er afsluttet og distribuerer den til //maven.springframework.org/milestone.

En frigivelseskandidat (RC1, RC2, RC3, ...) er det sidste trin inden opbygning af den endelige udgivelse. For at minimere kodeændringer bør kun fejlrettelser forekomme på dette trin. Det distribueres også til //maven.springframework.org/milestone.

I slutningen af ​​frigivelsesprocessen producerer Spring-teamet en RELEASE. Derfor er dette normalt den eneste produktionsklare artefakt. Vi kan også henvise til denne udgivelse som GA, for generel tilgængelighed.

Disse etiketter er alfabetisk ordnet for at sikre, at build- og afhængighedsadministratorer korrekt bestemmer, om en version er nyere end en anden. For eksempel betragtede Maven 2 fejlagtigt 1.0-SNAPSHOT som nyere end 1.0-RELEASE. Maven 3 fik fast denne adfærd. Som en konsekvens kan vi opleve mærkelig opførsel, når vores navneskema ikke er optimal.

3. Paraplyprojekter

Paraplyprojekter, som Spring Cloud og Spring Data, er projekter over uafhængige, men relaterede delprojekter. For at undgå konflikter med disse underprojekter vedtager et paraplyprojekt et andet navngivningsskema. I stedet for en nummereret version har hvert udgivelsestog et specielt navn.

I alfabetisk rækkefølge er Londons undergrundsstationer inspirationen til Spring Cloud-frigivelsesnavne - for startere, Angel, Brixton, Finchley, Greenwich og Hoxton.

Ud over foråret etiketter vist ovenfor, det definerer også et Service Release-mærke (SR1, SR2 ...). Hvis vi finder en kritisk fejl, kan der produceres en serviceudgivelse.

Det er vigtigt at indse, at en Spring Cloud-udgivelse kun er kompatibel med en specifik Spring Boot-version. Som en reference indeholder Spring Cloud Project-siden kompatibilitetstabellen.

4. Konklusion

Som vist ovenfor er det vigtigt at have en klar version-navngivningsplan. Selvom nogle udgivelser som milepæle eller udgivelseskandidater kan være stabile, bør vi altid bruge produktionsklare artefakter. Hvad er dit navneskema? Hvilke fordele har den i forhold til denne?