New range strategy for Composer to help libraries deal with multiple supported PHP versions

[Xerkus]

What would you like Renovate to be able to do?

I would like a new smart strategy that would support multiple version constrains tailored to make dependency available for all supported PHP version.

In the most basic form, strategy would behave as bump strategy in regards to minimum supported PHP version and as widen strategy for maximum supported PHP.

Given dependency xerkus/example with versions:

• 1.0 wants php ^7.3
• 1.1 wants ^7.4
• 1.2 wants php ^7.4 || ~8.0.0
• 2.0 wants php ~8.0.0 || ~8.1.0
• 2.1 wants php ~8.1.0
• 3.0 wants php ~8.1.0

With the following constraint for php version:

• ^7.3: Renovate would keep xerkus/example as ^1.0
• ^7.3 || ~8.0.0: Renovate will widen dependency to ^1.0 || ^2.0
• ^7.4 || ~8.0.0: Renovate will bump dependency to ^1.2 || ^2.0
• ^7.4 || ~8.0.0 || ~8.1.0: Renovate will widen dependency from ^1.2 || ^2.0 to ^1.2 || ^2.0 || ^3.0 while from ^1.2 it will widen to ^1.2 || ^3.0

There is a matter of all the minor PHP versions in between but I suspect it would not be really feasible to manage. For this reason I stated in the last example that ^2.0 would be skipped over if not already present.

If you have any ideas on how this should be implemented, please tell us here.

None. I did not look at the Renovate code yet.

Is this a feature you are interested in implementing yourself?

Maybe

[HonkingGoose]

I found two issues that might be related to this one:

• Composer/Packagist: support platform compatibility during lookup #2355
• Composer: Support stability constraints for packages #4542

[Xerkus]

The specific case I am looking into here is the need to maintain range for dependencies to make skeleton application installable on all of supported PHP versions with composer create-project. This all of requirement makes the case fairly niche and also distinct.

We dealt with very similar problem for our components already #13637

Since dependencies are declared as open ended ranges the bump strategy while setting platform to lowest minor php release works fairly well. I expect some issues about expanding range to include new major releases when they don't support set platform php version but required for the latest php releases.

Generally, in the absence of lock file maintenance, this strategy I think would be better suitable for libraries than having to deal with explicit constraint or platform overrides setting lowest minor php version. For us at Laminas it won't make much difference outside of skeleton because we do use lock files for testing so we would need to provide explicit php version for that anyway.

---

In my wishful thinking I would like to have dependencies managed in a way that would be resolved for each of minor php version and then combined. Assume for each of php minor there are following versions available:

• 7.3 - 1.0 to 1.0 with bump range ^1.0.0
• 7.4 - 1.0 to 1.2 with range ^1.2.0
• 8.0 - 1.2 to 2.1 with range ^2.1.0
• 8.1 - 2.0 to 3.0 with range ^3.0.0

So, combined we are looking at ^1.0.0 || ^1.2.0 || ^2.1.0 || ^3.0.0.

Renovate does not use composer to resolve dependencies, and dependency 2.1.0 might in turn depend on something that wants PHP 8.1, which will make range for php 8.0 to be effectively ^2.0.0. Composer itself does not resolve php requirement via indirect dependencies when doing composer require some/dependency I believe so I can only conclude that it is an expensive thing to figure out in the best of cases.

[rarkins]

It does seem like #2355 would be an important first step?