Namensschema für Spring Projects-Versionen

1. Übersicht

Es ist üblich, bei der Benennung von Release-Versionen die semantische Versionierung zu verwenden. Diese Regeln gelten beispielsweise für ein Versionsformat wie MAJOR.MINOR.REVISION :

  • MAJOR: Wichtige Funktionen und mögliche Änderungen
  • MINOR: Abwärtskompatible Funktionen
  • REVISION : Abwärtskompatible Korrekturen und Verbesserungen

Zusammen mit der semantischen Versionierung verwenden Projekte häufig Labels, um den Status einer bestimmten Version weiter zu klären. Mithilfe dieser Beschriftungen geben wir Hinweise zum Build-Lebenszyklus oder wo Artefakte veröffentlicht werden.

In diesem kurzen Artikel werden wir die Versionsbenennungsschemata untersuchen, die von großen Spring-Projekten übernommen wurden.

2. Spring Framework und Spring Boot

Zusätzlich zur semantischen Versionierung können wir sehen, dass Spring Framework und Spring Boot diese Bezeichnungen verwenden:

  • BUILD-SNAPSHOT
  • M [ Nummer ]
  • RC [ Nummer ]
  • FREISETZUNG

BUILD-SNAPSHOT ist die aktuelle Entwicklungsversion. Das Spring-Team erstellt dieses Artefakt jeden Tag und stellt es unter //maven.springframework.org/snapshot bereit.

Eine Meilensteinfreigabe (M1, M2, M3,…) markiert eine wichtige Phase im Freigabeprozess. Das Team erstellt dieses Artefakt nach Abschluss einer Entwicklungsiteration und stellt es unter //maven.springframework.org/milestone bereit.

Ein Release Candidate (RC1, RC2, RC3,…) ist der letzte Schritt vor dem Erstellen des endgültigen Releases. Um Codeänderungen zu minimieren, sollten zu diesem Zeitpunkt nur Fehlerbehebungen durchgeführt werden. Es wird auch unter //maven.springframework.org/milestone bereitgestellt.

Ganz am Ende des Release-Prozesses erstellt das Spring-Team eine RELEASE. Folglich ist dies normalerweise das einzige produktionsbereite Artefakt. Wir können diese Version für die allgemeine Verfügbarkeit auch als GA bezeichnen .

Diese Beschriftungen sind alphabetisch sortiert , um sicherzustellen, dass Build- und Abhängigkeitsmanager korrekt bestimmen, ob eine Version aktueller als eine andere ist. Zum Beispiel hat Maven 2 1.0-SNAPSHOT fälschlicherweise als neuer als 1.0-RELEASE angesehen. Maven 3 hat dieses Verhalten behoben. Infolgedessen können seltsame Verhaltensweisen auftreten, wenn unser Namensschema nicht optimal ist.

3. Dachprojekte

Umbrella-Projekte wie Spring Cloud und Spring Data sind Projekte über unabhängige, aber verwandte Teilprojekte. Um Konflikte mit diesen Teilprojekten zu vermeiden, verwendet ein Dachprojekt ein anderes Namensschema. Anstelle einer nummerierten Version hat jeder Release Train einen speziellen Namen.

In alphabetischer Reihenfolge sind die Londoner U-Bahn-Stationen die Inspiration für die Release-Namen der Spring Cloud - für den Anfang Angel, Brixton, Finchley, Greenwich und Hoxton.

Zusätzlich zu den oben gezeigten Federetiketten wird auch ein Service Release-Etikett (SR1, SR2…) definiert . Wenn wir einen kritischen Fehler finden, kann ein Service Release erstellt werden.

Es ist wichtig zu wissen, dass eine Spring Cloud-Version nur mit einer bestimmten Spring Boot-Version kompatibel ist. Als Referenz enthält die Seite Spring Cloud Project die Kompatibilitätstabelle.

4. Fazit

Wie oben gezeigt, ist ein klares Versionsbenennungsschema wichtig. Während einige Releases wie Milestones oder Release Candidates stabil sein können, sollten wir immer produktionsbereite Artefakte verwenden. Wie lautet Ihr Namensschema? Welche Vorteile hat es gegenüber diesem?