Navneplan for versjonsprosjekter

1. Oversikt

Det er vanlig å bruke Semantic Versioning når man navngir utgivelsesversjoner. Disse reglene gjelder for eksempel for et versjonsformat som STOR.MINOR.REVISJON:

  • STOR: Hovedtrekk og potensielle bruddendringer
  • MINDER: bakoverkompatible funksjoner
  • REVISJON: Bakoverkompatible rettelser og forbedringer

Sammen med Semantic Versioning bruker prosjekter ofte etiketter for å avklare tilstanden til en bestemt utgivelse. Ved å bruke disse etikettene gir vi faktisk tips om byggesyklusen eller hvor gjenstander blir publisert.

I denne raske artikkelen vil vi undersøke versjonsnavnene som ble vedtatt av store vårprosjekter.

2. Spring Framework og Spring Boot

I tillegg til semantisk versjon kan vi se at Spring Framework og Spring Boot bruker disse etikettene:

  • BYGG-STILLBILDE
  • M [Nummer]
  • RC [Nummer]
  • UTGIVELSE

BUILD-SNAPSHOT er den nåværende utviklingsversjonen. Vårt team bygger denne gjenstanden hver dag og distribuerer den til //maven.springframework.org/snapshot.

En Milestone-utgivelse (M1, M2, M3, ...) markerer et betydelig trinn i utgivelsesprosessen. Teamet bygger denne gjenstanden når en utvikling iterasjon er fullført og distribuerer den til //maven.springframework.org/milestone.

En utgivelseskandidat (RC1, RC2, RC3, ...) er det siste trinnet før du bygger den endelige utgivelsen. For å minimere kodeendringer, bør bare feilrettinger forekomme på dette stadiet. Den distribueres også til //maven.springframework.org/milestone.

Helt på slutten av utgivelsesprosessen produserer Spring-teamet en RELEASE. Derfor er dette vanligvis den eneste produksjonsklare artefakten. Vi kan også referere til denne utgivelsen som GA, for generell tilgjengelighet.

Disse merkelappene er alfabetisk ordnet for å sikre at bygnings- og avhengighetsansvarlige avgjør riktig om en versjon er nyere enn en annen. For eksempel betraktet Maven 2 feilaktig 1.0-SNAPSHOT som nyere enn 1.0-RELEASE. Maven 3 løste denne oppførselen. Som en konsekvens kan vi oppleve merkelig oppførsel når navneskemaet vårt ikke er optimalt.

3. Paraplyprosjekter

Paraplyprosjekter, som Spring Cloud og Spring Data, er prosjekter over uavhengige, men relaterte delprosjekter. For å unngå konflikter med disse delprosjektene, vedtar et paraplyprosjekt en annen navngivningsplan. I stedet for en nummerert versjon har hvert utgivelsestog et spesielt navn.

I alfabetisk rekkefølge er tunnelbanestasjonene i London inspirasjonen til Spring Cloud-utgivelsesnavnene - for startere, Angel, Brixton, Finchley, Greenwich og Hoxton.

I tillegg til våretiketter vist ovenfor, er det definerer også en Service Release-etikett (SR1, SR2 ...). Hvis vi finner en kritisk feil, kan en tjenestemelding produseres.

Det er viktig å innse at en Spring Cloud-utgivelse bare er kompatibel med en spesifikk Spring Boot-versjon. Som en referanse inneholder Spring Cloud Project-siden kompatibilitetstabellen.

4. Konklusjon

Som vist ovenfor er det viktig å ha et klart versjonsnavn. Selv om noen utgivelser som milepæler eller utgivelseskandidater kan være stabile, bør vi alltid bruke produksjonsklare gjenstander. Hva er navnet ditt? Hvilke fordeler har den fremfor denne?


$config[zx-auto] not found$config[zx-overlay] not found