-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow to enforce a minimum Quarkus Core version for a given extension version #37169
Comments
/cc @aloubyansky (extension-proposal), @gastaldi (extension-proposal), @gsmet (extension-proposal), @maxandersen (extension-proposal) |
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 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 :) |
btw. qarkus update and quarkus info is where we have ways to help/warn the user today. |
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. |
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. |
How about introducing a Build Item ( |
It would be nice if we could backport it on previous versions 🤣 |
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 |
the question is, do we have access to the Quarkus version? |
I guess you meant building an application? |
Does it have to be a build item? |
Not necessarily, just wanted an API that extensions could use to validate the deployment |
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
cc @aloubyansky @gastaldi @max
The text was updated successfully, but these errors were encountered: