-
Notifications
You must be signed in to change notification settings - Fork 348
chore(model): Remove IVY_VERSION_RANGE_INDICATORS
#10441
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -28,15 +28,10 @@ import org.semver4j.RangesListFactory | |
import org.semver4j.Semver | ||
|
||
/** | ||
* A list of Strings that are used by Ivy-style version ranges. | ||
* Return true if the version of this [Identifier] interpreted as an Ivy, NPM or CocoaPods version range is applicable | ||
* to the package with the given [identifier][pkgId]. | ||
*/ | ||
private val IVY_VERSION_RANGE_INDICATORS = listOf(",", "~", "*", "+", ">", "<", "=", " - ", "^", ".x", "||") | ||
|
||
/** | ||
* Return true if the version of this [Identifier] interpreted as an Ivy version matcher is applicable to the | ||
* package with the given [identifier][pkgId]. | ||
*/ | ||
internal fun Identifier.isApplicableIvyVersion(pkgId: Identifier) = | ||
internal fun Identifier.isApplicableVersionRangeFor(pkgId: Identifier) = | ||
runCatching { | ||
if (version == pkgId.version) return true | ||
|
||
|
@@ -66,7 +61,7 @@ internal fun Identifier.isVersionRange(): Boolean { | |
} | ||
|
||
private fun Identifier.getVersionRanges(): RangesList? { | ||
if (IVY_VERSION_RANGE_INDICATORS.none { version.contains(it, ignoreCase = true) }) return null | ||
if (version.isEmpty()) return null | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This function now more often return non-null, compared before. In such cases, the version is not interpreted just as plain version string anymore, but as version range. (Do you plan to make a release for #10434, and if so, can we wait with this PR until after this release is created?) Note: Before, version range semantics were limited to string containing any of There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
How do you know? It's just that fewer cases are caught by the early return; but all other cases should still return There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
True, I don't - but I'm actually looking for an explanation whether we now support additional ways of specifying version ranges. Do you know? Do you consider this change to be non-function, so basically just dropping some potential performance optimization? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I'm not sure what you mean. Ever since 8142cdc we have implicitly supported not only Ivy, but also NPM and CocoaPods version ranges. It just was never documented.
Yes. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I could do a patch-release if requested, but the merge if this PR does not have to wait necessarily, as releases can also be done for tags for past commits. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Can you share the explanation why the change is non-functional? This would also resolve
...by now we only supported version ranges which have at least one of the version range indiciator chars. So, you are saying that There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I simply have no indication why it should not be non-functional.
Yes. I mean, that was the point of @MarcelBochtler's change in 883e56c: The indicators were designed after the version ranges that the Semver library supports. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So, can we make this more clear in the commit message that this change is intended to be non-functional along with a rationale why?
This part of the commit message is a bit misleading, because the |
||
|
||
return runCatching { | ||
RangesListFactory.create(version).takeUnless { it.get().isEmpty() } | ||
|
Uh oh!
There was an error while loading. Please reload this page.