You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Current behaviour:
Take the latest, sorting by extensionRelease.sortableVersion, implemented in SQL. At the moment, that would be 3.0.0.Alpha1.
Proposed new behaviour:
Prefer extensions in recommended releases. ie at the moment, return 2.14.1 extensions. This is partly about going for .Final versions rather than .Alpha versions, and partly about looking at recommendedStream.id and preferring extensions which are members of those streams.
Proposed new implementation:
This might be too hard to manage in SQL, so we would probably need to fetch all extensions and then do a manual function to inspect the .qualifiers and cross-reference against platform information.
Secondary question:
If the same version of an extension participates in two platforms, how do we choose which platform is 'latest'? Most likely, the names of the platforms would be different, so we can't just use a version comparison. If one is recommended that would help, but if both are neither are recommended, what do we do? This doesn't affect the version in extensions/all, but it does affect what metadata appears attached to the extension. See quarkusio/extensions#24 for more discussion of this.
Tertiary question:
Should we provide/encourage a mechanism for a new version of a platform extensions to be published in the registry, without a new platform release? If such a version did appear in the registry it would automatically appear in extensions/all, so no 'latest version identification' code change would be needed. In other words, if that's the problem we're actually trying to solve, we need to look at the extension release logic, not the version-sorting logic.
The text was updated successfully, but these errors were encountered:
We currently expose a list of all extensions at http://registry.quarkus.io/client/extensions/all/
Current behaviour:
Take the latest, sorting by
extensionRelease.sortableVersion
, implemented in SQL. At the moment, that would be 3.0.0.Alpha1.Proposed new behaviour:
Prefer extensions in recommended releases. ie at the moment, return 2.14.1 extensions. This is partly about going for .Final versions rather than .Alpha versions, and partly about looking at
recommendedStream.id
and preferring extensions which are members of those streams.Proposed new implementation:
This might be too hard to manage in SQL, so we would probably need to fetch all extensions and then do a manual function to inspect the .qualifiers and cross-reference against platform information.
Secondary question:
If the same version of an extension participates in two platforms, how do we choose which platform is 'latest'? Most likely, the names of the platforms would be different, so we can't just use a version comparison. If one is recommended that would help, but if both are neither are recommended, what do we do? This doesn't affect the version in
extensions/all
, but it does affect what metadata appears attached to the extension. See quarkusio/extensions#24 for more discussion of this.Tertiary question:
Should we provide/encourage a mechanism for a new version of a platform extensions to be published in the registry, without a new platform release? If such a version did appear in the registry it would automatically appear in
extensions/all
, so no 'latest version identification' code change would be needed. In other words, if that's the problem we're actually trying to solve, we need to look at the extension release logic, not the version-sorting logic.The text was updated successfully, but these errors were encountered: