Allow to enforce a minimum Quarkus Core version for a given extension version

[ia3andy]

Description

Currently there is a notion of the version of Quarkus core used for building an extension (and it will reflect on the tooling).

Users can still easily change the version of Quarkus or extensions in the pom.xml leading to possible issues: No class def found, Methods, ..., but also sometime it may build and work but without critical features (security, ...).

It is important to provide a proper way to enforce when releasing an extension that user apps will be built using a compatible version of Quarkus (and fail with an informative message otherwise).

Implementation ideas

• A flag to specify that the build with quarkus core version needs to be enforced as minimum.
• Or make it the default behavior and give the word to not bump Quarkus Core version in extensions when it's not required (I think it's already what we recommend).

cc @aloubyansky @gastaldi @max

[quarkus-bot[bot]]

/cc @aloubyansky (extension-proposal), @gastaldi (extension-proposal), @gsmet (extension-proposal), @maxandersen (extension-proposal)

[maxandersen]

I'm failing to see how this is specific to quarkus - this can happen for literally any jar dependency and a single extension saying "No, do NOT build with a different version" is not going to work well.

"make sure we don't update Quarkus Core version in extensions when it's not required." is exactly what we recommend that is how one stay compatible with things.

issue is ofcourse that the world is currently falling pretty to "dependabot told me to update" and do that blindly. We need to stop shooting ourselves in the foot :)

[maxandersen]

btw. qarkus update and quarkus info is where we have ways to help/warn the user today.

[ia3andy]

I'm failing to see how this is specific to quarkus - this can happen for literally any jar dependency and a single extension saying "No, do NOT build with a different version" is not going to work well.

"make sure we don't update Quarkus Core version in extensions when it's not required." is exactly what we recommend

• its how one stay compatible with things.

What I mean is to say "you need to upgrade the Quarkus version for it to be compatible with this extension version". This is not what you are saying I think.

I am not talking about locking to a specific version of Quarkus but having a minimum version to enforce.

I don't see any reason why we should keep building user projects when we know it will fail and be incompatible! We have the possibility to enforce it, why not do it.

[ia3andy]

Today I released Quarkus Web Bundler 1.3.0 which is compatible from Quarkus 3.7.3 and onward, with a lower Quarkus version it will build but there might be issues really hard to catch.

This kind of scenario is really bad for users as there is no way to warn them about this incompatibility.

[gastaldi]

How about introducing a Build Item (MinimumQuarkusVersionBuildItem) that extensions could produce and create a consumer in core that checks whether the minimum Quarkus version is in range and fails the build if not?

[ia3andy]

It would be nice if we could backport it on previous versions 🤣

[gastaldi]

We could have that as a separate extension and move to core later on. Then people would just need to add a dependency to this extra extension to perform the check (Quarkiverse rules!)

Maybe call it quarkus-enforcer?

[ia3andy]

the question is, do we have access to the Quarkus version?

[aloubyansky]

Currently there is a notion of the version of Quarkus core used for building an extension

I guess you meant building an application?

[dmlloyd]

How about introducing a Build Item (MinimumQuarkusVersionBuildItem)

Does it have to be a build item?

[gastaldi]

Does it have to be a build item?

Not necessarily, just wanted an API that extensions could use to validate the deployment