allow testing of new unstable PHP versions as draft PRs

[internalsystemerror]

Q	A
Documentation	yes
Bugfix	no
BC Break	no
New Feature	yes
RFC	no
QA	yes

Description

In order to test out support for PHP 8.2, this PR will:

• Modify renovate to create PRs for new unstable PHP versions.
• These PRs will not automerge, even if the checks are green and will be assigned the "Awaiting Maintainer Response" label.

[internalsystemerror]

Before merging this, we may want to look at testing this out in a downstream repo first by pointing the renovate config to this branch.

[Ocramius]

@internalsystemerror can you create a new repo pointing to your fork, perhaps?

[internalsystemerror]

@Ocramius Yup, taken a fork of service manager, enabled renovate for it, will test there and report back 👍

[internalsystemerror]

We'd have to create a tag, it won't work with branch names :(

[Ocramius]

Feel free to push a temporary tag here 👍

[internalsystemerror]

{
    "currentValue": "~7.4.0 || ~8.0.0 || ~8.1.0",
    "datasource": "packagist",
    "depIndex": 0,
    "depName": "php",
    "depType": "require",
    "skipReason": "unsupported",
    "updates": []
}

It seems that the PHP field is unsupported. So we may have to do it the old fashioned way.

[gsteel]

Maybe a crazy idea, but could we create a meta package for php as a composer dependency where we add tags for all the versions?

[Ocramius]

We can't publish such a package, though? 🤔

[internalsystemerror]

Adding support for this into renovate should be possible, though with only a month left, maybe not in that time frame.

[Ocramius]

If it's automation-tested, shouldn't be massive? 🤔

[internalsystemerror]

With renovatebot/renovate#18474 now merged, I was going to retest this, however after bringing my fork up to date, ~8.2.0 was already added so I was unable to test this specifically..

However, I think this PR would be fine to merge as the only thing we aren't already using in this change is ignoreUnstable which is pretty well documented here: https://docs.renovatebot.com/configuration-options/#ignoreunstable

By default, Renovate won't update any package versions to unstable versions (e.g. 4.0.0-rc3) unless the current version has the same major.minor.patch and was already unstable (e.g. it was already on 4.0.0-rc2). Renovate will also not "jump" unstable versions automatically, e.g. if you are on 4.0.0-rc2 and newer versions 4.0.0 and 4.1.0-alpha.1 exist then Renovate will update you to 4.0.0 only. If you need to force permanent unstable updates for a package, you can add a package rule setting ignoreUnstable to false.

If we don't want to use unstable tags, I will update this PR to just disable the automerge and await maintainer response.

[Ocramius]

@internalsystemerror before this goes in: how is renovate deciding to apply this only to minor releases? 🤔

[internalsystemerror]

@Ocramius Sorry, I'm not sure I understand the question there? Do you mean the updates that renovate is offering? Or the branch that it applies to?

[Ocramius]

Let me clarify:

• assume our dependency range is ~8.3.0
• assume PHP 8.3.1-rc1 is available

Do we care about an upgrade here? How does renovate only consider 8.4.0-rc1 as worth inspecting?

[internalsystemerror]

Ah thanks, I get you! That would be handled by the rangeStrategy setting of "widen" for anything in "require":

.github/renovate-config.json

Line 26 in cbcde24

{"matchDepTypes": ["require"], "rangeStrategy": "widen"},

The widen strategy will add the || ~8.4.0-rc1 when that is released but not || ~8.3.0-rc1 as that already matches the current constraint of ~8.3.0. In fact it may decide to add || ^8.4.0-rc1 I'm not entirely certain, I would hope renovate is smart enough to figure out the correct constraint as it already does when replacing the version number, but if not we can look at that if/when we come to it.

[gsteel]

Off topic here, but do you think it's worth bump-ing require-dev instead of widen-ing?

[Ocramius]

That would be handled by the rangeStrategy setting of "widen" for anything in "require":

Thanks for clarifying!

Off topic here, but do you think it's worth bump-ing require-dev instead of widen-ing?

Bumping require-dev: yes please!

[Ocramius]

Let's try this out 👍