Quarkus Almanac vergleicht zwei Releases nach Konfiguration, BOM und API
Victoria Shinder2 Min. LesezeitOb ein Upgrade wehtut, hieß bisher: Migrationsleitfäden, Release Notes, BOM und Konfigurationsreferenz nebeneinander lesen. Das Quarkus-Team hat eine Website veröffentlicht, die den Vergleich übernimmt: Der Quarkus Almanac unter https://quarkus.io/almanac/ nimmt zwei beliebige Quarkus-Releases und listet auf, was sich zwischen ihnen geändert hat.
Das Werkzeug umfasst jedes Release ab 0.0.1 und folgt dem Vorbild von javaalmanac.io, dem Java Version Almanac. Ein Vergleich beginnt mit einer Zählung der Änderungen nach Art, darunter folgen einklappbare Abschnitte. Configuration zeigt Properties, die hinzukamen, entfielen oder veraltet sind oder deren Standardwert, Typ, erlaubte Werte oder Phase sich änderten, gruppiert nach Extension. Dependencies listet Upgrades, Downgrades, Neuzugänge und Entfernungen im verwalteten BOM. Extensions zeigt Neuzugänge, Entfernungen und Statuswechsel; zwischen den LTS-Releases 3.27 und 3.33 etwa entfielen die Derby-Extensions, und CycloneDX und Security wurden stabil.
Ein Detail, das man kennen sollte: Anwendungen von code.quarkus.io importieren das Plattform-BOM, das manchmal andere Versionen verwaltet als das Core-BOM. Der Almanac vergleicht standardmäßig die Plattform-BOMs; von 3.33.3.3 auf 3.33.4 hebt das Plattform-BOM 68 Jackson-Artefakte von 2.21.6 auf 2.21.7, während das Core-BOM bleibt. Ein Schalter vergleicht stattdessen die Core-BOMs.
Der API-Abschnitt entsteht aus den Klassendateien aller Quarkus-JARs und listet öffentliche und geschützte Elemente, die hinzukamen, entfielen, veraltet sind oder sich änderten. Jede Property, jedes Artefakt und jede Klasse hat eine Verlaufsseite; QuarkusUnitTest etwa wechselte in 3.31 das JAR, wurde in 3.35 zur Entfernung vorgemerkt und fehlt in 4.0.0.Beta2. Die Daten stammen aus Maven Central, ein GitHub-Workflow ergänzt alle zwölf Stunden neue Releases, und die Website ist statisch, die Vergleiche rechnet der Browser.
Was das bedeutet
Das Upgrade-Risiko steckt genau dort, wo Release Notes am wenigsten zusammenfassen: geänderte Standardwerte, abweichende BOM-Versionen und veraltete Test-APIs. Eine Historie pro Klasse und pro Property, abgeleitet aus den veröffentlichten Artefakten, ist eine bessere Quelle als Prosa, solange man im Kopf behält, dass sie zeigt, was sich geändert hat, nicht ob der eigene Code davon abhängt.