Quarkus Almanac turns release history into an upgrade-planning diff

Quarkus has put a structured diff in front of its release history. The Quarkus Almanac lets application and platform teams choose two releases and compare configuration properties, managed dependencies, extensions and the public or protected API of Quarkus jars.

That is more useful for upgrade planning than another changelog index. Release notes explain notable changes one release at a time; the Almanac answers a different question: what changed across the exact span an estate plans to cross?

What the comparison exposes

The tool separates four kinds of drift. It reports quarkus.* configuration properties that were added, removed or changed; dependency versions managed by either the core BOM or the platform BOM imported by projects generated at code.quarkus.io; extension additions, removals and relocations; and classes, methods and fields that were added, removed, deprecated or moved between jars.

A comparison from Quarkus 3.33.4.1 to 3.40.1.1, for example, currently reports 209 configuration additions, three removals and 59 changes. It also finds 115 changed managed dependencies, 11 added extensions, and hundreds of Java API additions, removals and changes. Those totals are not an upgrade verdict, but they are an efficient triage list: teams can move first to changed defaults, removed properties, major dependency jumps and APIs marked for removal.

The site also gives individual configuration properties, managed artifacts and classes their own history pages. That makes the diff useful beyond a single migration window: maintainers can identify when a change first appeared rather than searching release notes backward.

Where platform teams should be careful

The project README documents important boundaries. Only core extensions managed by quarkus-bom are included. Configuration before 3.25 is reconstructed from bytecode, and API signatures are erased, so changes involving generics or throws clauses alone do not appear. The API view also includes Quarkus internals and excludes some jars and shaded packages.

Dependency review needs one more choice. The core BOM and io.quarkus.platform:quarkus-bom can differ because the platform aligns Quarkus with other platform members. Application teams should compare the platform BOM when that is what their builds actually import.

Why this matters

The Almanac is generated from published artifacts rather than hand-maintained summaries. Its Java 21 extractor reads BOMs, configuration and extension metadata, and jar class files from Maven Central; extracted releases are retained as sorted JSON Lines, while comparisons run in the browser. A scheduled workflow checks for new releases every 12 hours after a six-hour publication delay.

That makes the tool best treated as an evidence layer for migration work: generate the diff for the current and target streams, turn the high-risk categories into test and remediation tasks, then confirm behavior in the relevant migration guides and application tests. It does not replace those guides, but it closes a practical gap between broad release notes and the exact change surface of a real upgrade.