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
Have you considered any alternatives or workarounds?
Any additional context
This (removed) behavior can be useful if you want to strictly rely on parent-provided versions, and implicitly "distrust" the validity of existing pinned versions (or anticipate that they will become a problem eventually as the parent version increases)
Yes -- mainly opening this issue first in case anyone has design input.
The least-intrusive implementation would be a new, additional flag, such as removeNewerVersions, which works in conjunction with onlyIfVersionsMatch. But the naming/usage starts to get fuzzy -- what if someone sets onlyIfVersionsMatchtrue and also removeNewerVersionstrue? We can validate those cases out, but, it's unintuitive.
Could also argue that onlyIfVersionsMatch is now an inaccurate name, since on false, it does not remove non-matching newer versions.
Replacing this field with some kind of removalStrategy enum could be nice, with values like matching, older, any, but replacing an arg like that can be disruptive for existing usage, and naming the new arg also takes some good thought (I don't love the value names I just suggested, eg).
Eager for any opinions
The text was updated successfully, but these errors were encountered:
maybe replace onlyIfVersionsMatch with onlyIfManagedVersionIs, with the value being a comparator symbol? eg =, <, >=?
and maybe * for "remove any relevant version regardless of value"?
default would be = to match default behavior of existing arg; could also interpret any number of = characters all the same way in case someone has muscle memory for == or ===
or maybe avoiding special characters is desirable for yaml, and instead could do eq,lt, gte, etc
What problem are you trying to solve?
Add an option for the functionality removed in this commit:
687fbb5
(from @sambsnyd )
What precondition(s) should be checked before applying this recipe?
N/A
Describe the situation before applying the recipe
Describe the situation after applying the recipe
Have you considered any alternatives or workarounds?
Any additional context
This (removed) behavior can be useful if you want to strictly rely on parent-provided versions, and implicitly "distrust" the validity of existing pinned versions (or anticipate that they will become a problem eventually as the parent version increases)
Are you interested in contributing this recipe to OpenRewrite?
Yes -- mainly opening this issue first in case anyone has design input.
The least-intrusive implementation would be a new, additional flag, such as
removeNewerVersions
, which works in conjunction withonlyIfVersionsMatch
. But the naming/usage starts to get fuzzy -- what if someone setsonlyIfVersionsMatch
true
and alsoremoveNewerVersions
true
? We can validate those cases out, but, it's unintuitive.Could also argue that
onlyIfVersionsMatch
is now an inaccurate name, since onfalse
, it does not remove non-matching newer versions.Replacing this field with some kind of
removalStrategy
enum could be nice, with values likematching
,older
,any
, but replacing an arg like that can be disruptive for existing usage, and naming the new arg also takes some good thought (I don't love the value names I just suggested, eg).Eager for any opinions
The text was updated successfully, but these errors were encountered: