Dev News Daily ENDE

Quarkus Almanac diffs any two releases by config, BOM and class API

Deciding whether an upgrade will hurt used to mean reading migration guides, release notes, the BOM and the configuration reference side by side. The Quarkus team has published a site that does the comparison instead: the Quarkus Almanac, at https://quarkus.io/almanac/, takes any two Quarkus releases and lists what changed between them.

The tool covers every release from 0.0.1 onwards and is modelled on javaalmanac.io, the Java Version Almanac. A comparison opens with a count of changes by kind, followed by collapsible sections. Configuration shows properties that were added, removed or deprecated, or whose default, type, accepted values or phase changed, grouped by extension. Dependencies lists upgrades, downgrades, additions and removals in the managed BOM. Extensions shows additions, removals and status changes; between LTS releases 3.27 and 3.33, for example, the Derby extensions were removed and CycloneDX and Security became stable.

A detail worth knowing: applications generated by code.quarkus.io import the platform BOM, which sometimes manages different versions than the core BOM. The Almanac compares platform BOMs by default; from 3.33.3.3 to 3.33.4 the platform BOM moves 68 Jackson artifacts from 2.21.6 to 2.21.7 while the core BOM stays put. A switch compares the core BOMs instead.

The API section is built from the class files of every Quarkus jar, listing public and protected members that were added, removed, deprecated or changed. Every property, artifact and class has a history page; QuarkusUnitTest, for instance, moved jars in 3.31, was deprecated for removal in 3.35 and is gone in 4.0.0.Beta2. The data comes from Maven Central, a GitHub workflow adds new releases every twelve hours, and the site is static, with comparisons computed in the browser.

Quarkus Almanac diffs any two releases by config, BOM and class API
Quarkus Almanac diffs any two releases by config, BOM and class API — Dev News Daily

What it means

Upgrade risk lives in exactly the places release notes summarise least: changed defaults, BOM drift and deprecated test APIs. A per-class and per-property history derived from the published artifacts is a better source than prose, as long as readers remember it shows what changed, not whether their own code depends on it.

Written by Victoria Shinder.