Quarkus platform BOM revert leaves unresolved extension version mismatch

Question

The goal is to determine whether reverting quarkus.platform.version after an attempted Quarkus platform upgrade reliably realigns all Quarkus extensions with the reverted platform BOM. A failed or partial upgrade can leave extension versions from the newer release mixed with the reverted platform, but it is unclear whether the build tool regenerates a fully consistent resolution from the build configuration alone.
This is a design question for Quarkus 3.x, where the platform BOM governs extension alignment and no automatic rollback command is documented. Application code that depends on internal Quarkus or extension APIs may behave differently even if the BOM version appears correct.
Questions:

Does reverting quarkus.platform.version force every Quarkus extension back to the versions pinned by the reverted BOM?
Can stale dependency metadata preserve newer extension versions after the platform version is reverted and the project is rebuilt?
What check confirms that the resolved extension set matches the reverted Quarkus platform release?

Tasadduq Burney · Answer

Reverting the Quarkus Platform BOM
Reverting the quarkus.platform.version property does not automatically guarantee that every extension is realigned if the project configuration was modified during the upgrade attempt. While the BOM (Bill of Materials) defines the intended versions, the build tool's resolution logic takes precedence over the BOM in specific scenarios.

Likely Causes of Version Mismatch
In a standard Quarkus 3.x setup, the BOM manages versions for all io.quarkus artifacts. However, a revert may fail to align versions if:

Explicit Versioning: If extension versions were hardcoded in the pom.xml or build.gradle during the upgrade (rather than relying on the BOM), those explicit declarations override the reverted BOM.
  Transitive Overrides: Third-party libraries introduced during the upgrade may pull in newer versions of shared Quarkus dependencies as transitive requirements.
  IDE Cache: The build tool may have resolved the correct versions, but the IDE's internal model may still reference the newer artifacts until a project reload is triggered.

Steps to Ensure Full Alignment
To force a complete realignment with the reverted platform version, follow these steps:

Audit Dependency Declarations: Remove any explicit <version> tags from Quarkus extensions in your build file. Ensure they rely solely on the BOM management.
  Clear Local Resolution: Force the build tool to re-evaluate the graph. For Maven, use a clean build; for Gradle, use the --refresh-dependencies flag.
  Verify Resolved Graph: Use the following commands to inspect the actual versions being packaged into the application:

# For Maven
mvn dependency:tree -Dincludes=io.quarkus

# For Gradle
./gradlew dependencies --configuration compileClasspath | grep io.quarkus

Verification and Diagnostics
The only definitive check is the dependency tree. Compare the output of the commands above against the official release notes for your reverted version. If you see a mix of versions (e.g., some 3.x.1 and some 3.x.5), a dependency is overriding the BOM.

Required Diagnostic: Are you using any third-party "starter" libraries or custom BOMs that might be importing a different version of the Quarkus platform transitively?

Quarkus platform BOM revert leaves unresolved extension version mismatch

1 answer

Reverting the Quarkus Platform BOM

Likely Causes of Version Mismatch

Steps to Ensure Full Alignment

Verification and Diagnostics

Your perspective belongs here.

0 question comments