vlsi commented on issue #11391: URL: https://github.com/apache/maven/issues/11391#issuecomment-3531784632
> It really comes down to whether switching specific dependencies is a real use case or not In my experience, it is rarely used, however, it is useful. For instance, if a newer release brings a bug in one of the old methods, users might want to forcefully downgrade even if one of transitive deps specifies a newer version. Here's such a case in Gradle documentation: https://docs.gradle.org/current/userguide/how_to_prevent_accidental_dependency_upgrades.html#why_prevent_accidental_dependency_upgrades > If the user did switch to the new or updated highest strategy, and want to force a given dependency version I agree. For libraries, only ranges for `strict` make sense, and I believe for libraries, `strict` is not really needed in the first release. For example, GitHub search shows only a few usages of `strictly` in all Apache build scripts: https://github.com/search?q=org%3Aapache+strictly+path%3Agradle&type=code It might be, it would be good enough for the end users if the first release contains just a configuration option to flip between nearest vs highest (including direct ones). > implement in the future a strategy that requires the SHA-256 hash of modular JAR files to match It relates to dependency verification scenario which is orthogonal to resolution strategy. -- 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]
