Maintaining a requirements graph? #15057
Replies: 1 comment
-
As a general rule, we don't block/suppress updates because they need some other lib or tool upgraded first. If we did, we might end up with projects unaware of how out of date they are. A somewhat related example is how there's a bunch of libraries we depend on here which require ESM. If we completely suppressed those, we'd be in blissful ignorance of this problem, whereas now at least we know. But one approach I would like to adopt is using detected constraints to influence lookups, as long as we can also update those constraints. So for example we detect the Regarding your particular example, if the system requirement of |
Beta Was this translation helpful? Give feedback.
-
There are many dependencies, where upgrading to a new dependency requires upgrading other dependencies. For example, I asked Renovate to upgrade the lombok plugin, but it requires an upgrade of the gradle wrapper. If we could somehow tell this to Renovate, may maintaining some sort of graph with the requirements, we could save build minutes that are known to end in build failure.
If the requirements are known one might be able to block the upgrade beforehand, or include the upgrades of dependencies along with the requested package upgrade.
Was a thing like this ever considered? I must admit, that with a large number of OSS projects and an even bigger amount of version, this might not be feasible as a single shared repo for the entire world. In that case, just being able to do this within an organization may be beneficial.
Beta Was this translation helpful? Give feedback.
All reactions