It's nice to have a name for this, and for it to be quantifiable. I could see this on some kind of product dashboard - maybe automatically generated.
But, while I appreciate the need for simplicity, I also wonder if it would be wise to scale dependencies by how prevalent they are in the codebase. For example, if I'm using a five year old version of react but the library I use to convert temperature units is up-to-date, then thats bad. But if I'm using the latest react and the conversion lib is old then thats less bad.
The features that you described are somewhat close to what I'm trying to build with depshub.com. Dependency visibility is still a major problem in any engineering team that cares about dependencies, and it's often very hard to say if a project is moving in the right direction in terms of updates. Some teams just completely ignore the fact that they need to update dependencies, but this usually comes with the consequence of "updating ASAP because we need X feature or Y bugfix."
All the major tools (dependabot, renovate) to keep dependencies up to date treat all the dependencies equally when in reality there are always core libraries (e.g., react) and everything else. While trying to keep *everything* up to date is extremely challenging, what I'm trying to do is to find a balance between what and when needs to be updated (using code static analysis, different data sources, AI etc) and automate it in a simple manner.
Comments
It's nice to have a name for this, and for it to be quantifiable. I could see this on some kind of product dashboard - maybe automatically generated.
But, while I appreciate the need for simplicity, I also wonder if it would be wise to scale dependencies by how prevalent they are in the codebase. For example, if I'm using a five year old version of react but the library I use to convert temperature units is up-to-date, then thats bad. But if I'm using the latest react and the conversion lib is old then thats less bad.
Probably feature creep though...
The features that you described are somewhat close to what I'm trying to build with depshub.com. Dependency visibility is still a major problem in any engineering team that cares about dependencies, and it's often very hard to say if a project is moving in the right direction in terms of updates. Some teams just completely ignore the fact that they need to update dependencies, but this usually comes with the consequence of "updating ASAP because we need X feature or Y bugfix."
All the major tools (dependabot, renovate) to keep dependencies up to date treat all the dependencies equally when in reality there are always core libraries (e.g., react) and everything else. While trying to keep *everything* up to date is extremely challenging, what I'm trying to do is to find a balance between what and when needs to be updated (using code static analysis, different data sources, AI etc) and automate it in a simple manner.