[jimmaswell]

100% evil and pretentious. Not every dev team has the free time to go rewriting everything to the whimsy of library devs that can't help themselves from incessantly shuffling everything around every week. This is how you encourage people to never update and keep security vulnerabilities in the wild.

[pantelisk]

It is especially evil since on many systems old methods are more performant, because they were meant to be used on old limited hardware (where cycles and memory really mattered). So by making those slower... you 're really digging a hole. There are of course cases where the opposite is true too, like all things in life.

[izacus]

We're talking about transitions where the library authors deliberately want to (and have good reasons) to migrate whole organization over. It's not they who are pretentious in your scenario ;)

[hchz]

This is not a decision a library developer makes in a reasonable Engineering organization.

[nomel]

I think that really depends. If there are performance, compliance, or maintenance requirements for the new versions where this is being implemented, and devs are updating to, then it could be considered reasonable. You wouldn't be seeing these delays if you continue using old versions of the library. Freeze your dependencies if you don't want your dependencies to change.

[ddingus]

That seems like a mutual discussion, and seems to me this kind of thing happens when it isn't.

[laichzeit0]

Really? That’s basically the premise of every JavaScript web framework.

[flukus]

This is a failure of the dev team not evaluating that libraries are stable enough for their organization. If you can't keep up with the iterations of the libraries you're using then you shouldn't be using those libraries in the first place.