Skip to content
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

Open
ia3andy opened this issue Nov 17, 2023 · 12 comments
Open
Labels
area/devtools Issues/PR related to maven, gradle, platform and cli tooling/plugins area/quarkiverse This issue/PR is part of the Quarkiverse organization area/registry Quarkus Extension Registry kind/enhancement New feature or request

Comments

@ia3andy
Copy link
Contributor

ia3andy commented Nov 17, 2023

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

@ia3andy ia3andy added the kind/enhancement New feature or request label Nov 17, 2023
@ia3andy ia3andy added area/quarkiverse This issue/PR is part of the Quarkiverse organization area/registry Quarkus Extension Registry area/devtools Issues/PR related to maven, gradle, platform and cli tooling/plugins and removed triage/needs-triage labels Nov 17, 2023
@quarkus-bot
Copy link

quarkus-bot bot commented Nov 17, 2023

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

@maxandersen
Copy link
Member

maxandersen commented Nov 17, 2023

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
Copy link
Member

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

@ia3andy
Copy link
Contributor Author

ia3andy commented Nov 17, 2023

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
Copy link
Contributor Author

ia3andy commented Feb 20, 2024

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
Copy link
Contributor

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
Copy link
Contributor Author

ia3andy commented Jun 25, 2024

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

@gastaldi
Copy link
Contributor

gastaldi commented Jun 25, 2024

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
Copy link
Contributor Author

ia3andy commented Jun 25, 2024

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

@aloubyansky
Copy link
Member

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

I guess you meant building an application?

@dmlloyd
Copy link
Member

dmlloyd commented Jun 25, 2024

How about introducing a Build Item (MinimumQuarkusVersionBuildItem)

Does it have to be a build item?

@gastaldi
Copy link
Contributor

Does it have to be a build item?

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/devtools Issues/PR related to maven, gradle, platform and cli tooling/plugins area/quarkiverse This issue/PR is part of the Quarkiverse organization area/registry Quarkus Extension Registry kind/enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

5 participants