[tomaszsobota]

I agree with other comments that it's not a perfect measure but it's a solid step in the right direction from having no metrics at all.

The libs we're measuring up to could have their own libyears to upgrade, but we can only control what's in our hands.

Sometimes a small security patch is worth more than a major version bump of features, so I consider measuring the time instead of major versions a benefit.

[prmoustache]

I guess that having to rely on metrics to begin with means the battle is lost and your have no control on the code you are using.

Maybe we should stop boilerplating everything and write the actual code we need. For the most part softwares usually use a tiny fraction of capabilities of any given library.

Maybe before trying to limit our lag in dependencies update of unlimited levels of libraries we should focus first on having a maximum level of dependencies. Like one project would use a maximum of 2 level of libraries dependencies and you would have to rewrite those that have too many levels.

The javascript ecosystem for instance is totally unmanageable as I see it. We just pretend we have a bit of control but in reality nobody knows what code is executed really and this is sad.

[tomaszsobota]

That is better, I agree. I'd take a lean set of dependencies any day, but it becomes increasingly more difficult the more velocity the project gets.

Suddenly less and less is considered core and it's easier than ever to 'outsource' to external libs to save time. Or is it rather that the project gets more velocity because of that?

> We just pretend we have a bit of control but in reality nobody knows what code is executed really and this is sad.

True, this is also slowly starting to be the case with other languages. With Python it can be so bad that even attempting to 'build' and run the same project a year later may well fail. Much to what I'm used to with JavaScript projects by now.