Support Quarkus core version ranges in ExtensionReleaseCompatibility

[gastaldi]

Since it's hard to keep track of minor releases, it would be nice if ExtensionReleaseCompatibility supported version ranges in the quarkusCoreVersion

[gastaldi]

I've been thinking about it and I've come with some ideas:

• Create a PostgreSQL extension to support Maven format versions and version ranges (based on https://github.com/theory/pg-semver, because our versions are not semver-compatible )
• Store the minimum and maximum version from the parsed range in separate columns and compare them using the same format we use our versionSortable columns
• Read all version ranges from the DB to memory and perform the comparison in-memory using org.apache.maven.artifact.versioning.VersionRange

I personally like the first idea, which would allow comparing versions and version ranges using SQL directly, which could be interesting as a long term solution.

Any thoughts @aloubyansky ?

[aloubyansky]

I am wondering whether we should introduce an entity that would represent an extension catalog for a given quarkus version. It seems like it could solve a couple of issues.

1. This is what the registry serves primarily. I.e. typically a registry would receive a request to return an extension catalog. Instead of performing complex queries, we could look up an extension catalog by that quarkus version and return it if it's found. This should improve performance.
2. Whenever a new quarkus version is registered, we could also create an extension catalog for it. When a new extension version is added or an existing extension metadata is updated, we could process it's quarkus version ranges in the app code and update the corresponding quarkus version extension catalogs. For example, we could fetch all the quarkus versions present in the registry and use Java (Maven) API to find which of those fit the ranges configured in the extension metadata. This should avoid the need for version ranges support at the db level.

[gastaldi]

introduce an entity that would represent an extension catalog for a given quarkus version

I've thought about that in the beginning. The reason why I didn't follow was because I believed it would defeat the purpose of having a history of extension releases which could be useful for the (upcoming) extensions.quarkus.io, but maybe that' s not important now (the data is in central anyway). That is pretty similar of having a static website too (which could be regenerated whenever a change in the extension catalog is detected).

we could fetch all the quarkus versions present in the registry and use Java (Maven) API to find which of those fit the ranges configured in the extension metadata

@aloubyansky can you elaborate a bit more on this? One requirement I'd like to keep on the registry is that it must avoid any external network connectivity (for example: querying external Maven repositories). The main reason is that it's rather unlikely that the environment on which the app will run will have access to external URLs and also as it could raise security concerns which I'd prefer to avoid.

[aloubyansky]

I didn't mean to remove anything we currently have in the registry and the model. Just introduce a new entity.

By the Maven API I meant org.apache.maven.artifact.versioning package from the org.apache.maven:maven-artifact dependency. It allows comparing versions. Or the equivalent SmallRye impl. There should be a version range API somewhere too.