I recently spent an entire day tracking down the cause of an error message. The issue was a package which hadn't been updated in a while 
. I'd like to avoid similar pain in future - so I have two questions:
this is, for me, a matter of careful control over my libraries. I made the decision that I wanted to be able to restore my libraries to the approved configuration without needing an Internet connection. Thus, I downloaded all of the package source files I wanted to include in my libraries and stored them on a server. Making any updates to the libraries requires acting through the configuration management process. This forces me to be deliberate* and thoughtful about upgrading packages.
I just went through the upgrade process. it was a mixture of automated tests from some of my local packages and user-based tests in my shiny apps. Overall, it was a very smooth process.
install.packages isn't something I allow myself to use just because I want the latest feature. The process of upgrading my production library requires a non-trivial amount of paperwork.I had a very similar experience where an external collaborator updated their version of ggplot2 to a post-1.0 release while our team was still using a 0.9 release, which gave us a lot of lessons learned! In terms of updating packages, I very often use packrat to manage the package library for specific projects, which puts me back in control of when packages can be updated and if needed downgraded. Combined with using Git for version control, I can try out an upgrade to a package and if my code experiences a major breakage, I can simply roll back the update by reverting the commits used to upgrade the package(s). Another idea for testing out upgrades might be to utilize the rocker Docker images that could be spun up on demand if you have Docker available.