Add expiry date to packageRules

[niorg]

Locking a dependency to a certain version using 'allowedVersions' can be very useful if you know that it can't be upgraded anyway for a certain reason and you don't want to be bothered about it anymore. But it is a bit too aggressive in my opinion and I'd like to propose a solution.

The problem is that suppressing it indefinitely will also stop you from ever being aware of the outdated version, until you revisit the renovate.json. This can cause security issues if you largely depend on Renovate for upgrades. Also other upgrades might start to fail because they depend on the suppressed version.

Often you only want to block it until a certain condition is resolved. Maybe until new budget is allocated for the project in a couple of months time or until the version is planned to be stable or in LTS.

For example, I'm often using this option:

{
    "datasources": ["docker"], 
    "packageNames": ["openjdk"],
    "allowedVersions": "< 16.0.0"
 },

As the openjdk docker images include the unstable java version, I'd like to suppress those until the new stable version is actually shipping. As this has a regular cycle of 6 months, I'd actually prefer if I could add an expiry date to it. Something like this:

{
    "datasources": ["docker"], 
    "packageNames": ["openjdk"],
    "allowedVersions": "< 16.0.0",
    "expiryDate": "2020-10-01"
 },

This way you can get alerted about it right when you need it.

I hope you agree that this might be useful. But I'm not sure how feasible it is to implement though. Any suggestions?

[rarkins]

Might be useful to add both startDate and endDate fields at the same time.

I thought about ISO 8601 time intervals so it can be a single field, but that might be unnecessarily complex.