sultan commented on PR #1683:
URL: https://github.com/apache/maven-resolver/pull/1683#issuecomment-3656730307
Thank you for clarifying the current handling of qualifiers.
This may be acceptable, but IMHO it would be great if Maven could provide
more explicit reasoning and guidance:
* **Clarification of rationale**: Could you explain why certain qualifiers
(e.g. `sp` from Red Hat) are accepted, while others (like `preview` from
Microsoft) are not? Is this distinction based on legacy behaviour tied to the
date of introduction of qualifiers, or on community adoption patterns?
* **Version ordering issues**: Will the ordering problems that arise from
these differences be considered “no fix”, or is there room for improvement in
the resolver logic?
* **Specification transparency**: It would help if Maven documented this
behaviour in the specification, with the reasoning included, so that users
don’t repeatedly open issues about unexpected ordering.
* **Alternative schemes**: Would Maven be open to supporting a second
version scheme alongside the Generic one, to address these ordering problems
more systematically?
* **Ecosystem guidance**: Would Maven recommend that tools like Dependabot
define their own version scheme to handle these ordering inconsistencies, or
should the community expect Maven itself to provide a canonical solution?
* **Statement to vendors**: Could Maven also consider making a clear
statement to major vendors, encouraging them to avoid problematic qualifiers?
For example:
* Microsoft → stop using `preview`
* Red Hat → avoid `ga` and `sp1`
* Android → avoid `dev`
* (Positive example: Spring stopped using the `release` qualifier and
aligned with best practices)
Such a statement would help reduce confusion across the ecosystem and
promote consistent versioning practices.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
