[mcherm]

> Dealing with multiple library changes at once is an order of magnitude more difficult than dealing with them one-at-a-time.

Curious... I have exactly the opposite experience. I find that a certain amount of time is required to carefully regression-test my application code after upgrading a library. Doing this 23 times for my 23 different dependencies that need to be upgraded can be quite costly. If I, instead, upgrade all of the libraries at once and perform my extensive regression testing just once, I save a great deal of effort.

That's if everything goes smoothly. If something does NOT go smoothly and I encounter an error, then I need to determine which upgrade caused the problem. Most of the time (85% perhaps?), that turns out to be easy and obvious just by looking at the error that presents itself. In the remaining cases, I simply roll back half of the package upgrades and start binary-searching to identify the culprit (or culprits in the case of a conflict between libraries).

[bad_user]

Personally I agree with you, except that sometimes you find out that a library you depend on hasn't been upgraded and cannot be used in combination with your other libraries, due to some conflict somewhere. At which point one needs to drop the library from the project and that can prove to be costly, so it is better to identify libraries that aren't well maintained earlier rather than later. This isn't a problem for well established popular libraries, but is a problem if you're using newer, more cutting age stuff.

[calpaterson]

Do you have an automated testing suite? That might explain the difference in experience. I use a lot of automated tests

[mrottenkolber]

I don't think its the testing thats work intensive, its fixing things that broke. The more often you upgrade the more often things will break.

[calpaterson]

Maybe, but s/he did explicitly mention the regression testing taking a long time