A narrow rangeStrategy feature - kind of

[ns-ggeorgiev]

Type of discussion.

I'm proposing an idea

Tell us more.

I have libraries that define dependencies in ranges. I am using the rangeStrategy widen and this works great for the scenario when a new version is discovered.

Unlike pinning though, range widening does not help to drop dependencies that include vulnerabilities.

What I am looking for is, when the range strategy is widen renovate to recognize some sort of narrow property that would increment the lower side of the range.

With other words, if I have a range: >=1.2.3,<=2.3.4 and narrow=">=1.3.5" renovate should suggest a change >=1.3.5,<=2.3.4

[rarkins]

I'm not sure how to achieve it easily, but I think I understand the idea. It's a little related to these concepts:

• We used to kind of "bump" Node.js versions and constraints once a release left LTS. It proved hard to do so we removed the capability, but I'd like it back again one day
• Reminds me a bit of allowedVersions

I'm guessing that the reason for you asking is because you'd like to apply this as a centralized "policy" in a shared config, not because it's just for one repo only?

[rarkins]

In your case this is only applicable for when rangeStrategy=widen?

I also wonder whether you need to supply a constraint, like >=1.3.5, or whether instead it's a better semantic to supply a config like lowerBound=1.3.5. It's a lot simpler if we only need to evaluate a fixed version instead of any possible range the user could configure.

[ns-ggeorgiev]

In your case this is only applicable for when rangeStrategy=widen?

It seems so. All other strategies deal with a single pinned version, don't they? Maybe "bump" as well but I am not exactly sure how it works, I am not using it.

The issue is, do you want to have it >1.3.5 or >=1.3.5. Maybe the sign could be taken from the existing range, but this seems that it might result in unintended result. Because this suppose to be a central enforcement what if someone has his range > and someone else >=. It will make it impossible to express correctly with a single value.

[rarkins]

In your case this is only applicable for when rangeStrategy=widen?

It seems so. All other strategies deal with a single pinned version, don't they?

No, multiple strategies deal with ranges (replace, bump, update-lockfile, widen)

The issue is, do you want to have it >1.3.5 or >=1.3.5. Maybe the sign could be taken from the existing range, but this seems that it might result in unintended result. Because this suppose to be a central enforcement what if someone has his range > and someone else >=. It will make it impossible to express correctly with a single value.

I don't think there's a single practical example where you couldn't fine a "minimum version" and MUST have a "greater than". If we are stubborn about supporting impractical examples which may never exist then this is practically guaranteed to sit here as a Discussion without a solution

[ns-ggeorgiev]

Also since this is lower boundary - it should only allow constraint that limit the range from the bottom. In case of python these are only '>' and '>='.

[ns-ggeorgiev]

Wow, We use greater than almost exclusively. We have a matrix test that guarantees that ranges for different libraries are compatible. To allow for the logic that determines the matrix the lower and the upper boundaries need to be closed.

Seems like yet another feature that will go and stay in my fork.