Schema di denominazione delle versioni dei progetti di primavera

1. Panoramica

È comune utilizzare Semantic Versioning quando si nominano le versioni di rilascio. Ad esempio, queste regole si applicano a un formato di versione come MAJOR.MINOR.REVISION :

  • PRINCIPALE: caratteristiche principali e potenziali modifiche sostanziali
  • MINOR: caratteristiche compatibili con le versioni precedenti
  • REVISIONE : correzioni e miglioramenti compatibili con le versioni precedenti

Insieme al controllo delle versioni semantico, i progetti spesso utilizzano etichette per chiarire ulteriormente lo stato di una particolare versione. In effetti, utilizzando queste etichette diamo suggerimenti sul ciclo di vita della build o su dove vengono pubblicati gli artefatti.

In questo rapido articolo, esamineremo gli schemi di denominazione delle versioni adottati dai principali progetti Spring.

2. Spring Framework e Spring Boot

Oltre al controllo delle versioni semantico, possiamo vedere che Spring Framework e Spring Boot utilizzano queste etichette:

  • BUILD-SNAPSHOT
  • M [ numero ]
  • RC [ numero ]
  • PUBBLICAZIONE

BUILD-SNAPSHOT è l'attuale versione di sviluppo. Il team di Spring costruisce questo artefatto ogni giorno e lo distribuisce su //maven.springframework.org/snapshot.

Un rilascio Milestone (M1, M2, M3, ...) segna una tappa significativa nel processo di rilascio. Il team crea questo artefatto al termine di un'iterazione di sviluppo e lo distribuisce su //maven.springframework.org/milestone.

Un Release Candidate (RC1, RC2, RC3, ...) è l'ultimo passaggio prima di creare il rilascio finale. Per ridurre al minimo le modifiche al codice, in questa fase dovrebbero essere eseguite solo correzioni di bug. È anche distribuito a //maven.springframework.org/milestone.

Alla fine del processo di rilascio, il team di Spring produce un RELEASE. Di conseguenza, questo è solitamente l'unico artefatto pronto per la produzione. Possiamo anche fare riferimento a questa versione come GA, per disponibilità generale .

Queste etichette sono ordinate alfabeticamente per assicurarsi che i gestori di build e dipendenze determinino correttamente se una versione è più recente di un'altra. Ad esempio, Maven 2 ha erroneamente considerato 1.0-SNAPSHOT come più recente di 1.0-RELEASE. Maven 3 ha corretto questo comportamento. Di conseguenza, possiamo sperimentare strani comportamenti quando il nostro schema di denominazione non è ottimale.

3. Progetti ombrello

I progetti ombrello, come Spring Cloud e Spring Data, sono progetti su sottoprogetti indipendenti ma correlati. Per evitare conflitti con questi sottoprogetti, un progetto ombrello adotta uno schema di denominazione diverso. Invece di una versione numerata, ogni Release Train ha un nome speciale.

In ordine alfabetico, le stazioni della metropolitana di Londra sono l'ispirazione per i nomi delle versioni di Spring Cloud: per i principianti, Angel, Brixton, Finchley, Greenwich e Hoxton.

Oltre alle etichette Spring mostrate sopra, definisce anche un'etichetta Service Release (SR1, SR2…) . Se troviamo un bug critico, può essere prodotta una Service Release.

È importante rendersi conto che una versione di Spring Cloud è compatibile solo con una specifica versione di Spring Boot. Come riferimento, la pagina del progetto Spring Cloud contiene la tabella di compatibilità.

4. Conclusione

Come mostrato sopra, è importante disporre di un chiaro schema di denominazione delle versioni. Sebbene alcune versioni come Milestones o Release Candidate possano essere stabili, dovremmo sempre utilizzare artefatti pronti per la produzione. Qual è il tuo schema di denominazione? Quali vantaggi ha rispetto a questo?