George Gastaldi
George Gastaldi
@aloubyansky sorry I wasn't clear, I meant that we have the `built-with-quarkus-core: "3.8.4"` in the `quarkus-extension.yaml` metadata, not the minimum Quarkus version an extension supports
How about we introduce a `quarkus-core-compatibility: [3.8.4,)` metadata featuring a version range that could be checked somewhere in core? Default would be `[${built-with-quarkus-core},)`
Maybe use streams instead (no patch version). In theory we shouldn't introduce API changes in patch releases, but who knows :)
> Yes, I was thinking of quarkus-core major.minor as a start. +1, that's what I meant when I said to use streams
Closing as the requires-quarkus-core seems to suffice for now
I don't know, I believe that the absence of a predefined qualifier should assume `Final` or `RELEASE` for comparison purposes. Any thoughts @aloubyansky?
I'd say that Maven is wrong and so is Smallrye for not considering an empty milestone as a release during comparison 😀
@angelozerr that looks really cool, good job! Can we somehow also show the javadoc next to the class name (that explains what the build item is for)?
@angelozerr I agree with @fbricon's concerns here that using `&` seems arbitrary and unnatural. Although I understand the reason why it works that way, I think that having a separate...
As I reported in https://github.com/redhat-developer/intellij-quarkus/issues/1094, the idea is to have a search mechanism to find the intended build item while developing an extension. Although searching for `BuildItem` may display the...