What are the best-practices for upgrading gems to newer versions?What sort of tips and techniques can save time and headaches?If you don’t have adequate tests, then be ready to do some adequate manual testing.Even if you have lots of tests, you still need to do manual testing if you upgrade a UI library such as to see what got updated.I built this guide based on my real-world experiences over years of gem migrations, including a recent upgrade to Rails 4.1, RSpec 3.0, and Twitter Bootstrap 3.Here’s my favorite reasons for keeping gems relatively current: That being said, recent versions can have new bugs, so it’s best to avoid versions that are unreleased or that haven’t aged at least a few weeks.
Here’s an example of the syntax to specify the very-latest version of a gem (the tip of the master branch): Sometimes what you need is something less than the most current version, or a specific branch, or a fork of the gem. If you’ve never done this, it’s a very worthwhile thing to try out, and it’s easy!Unless you have a good reason, don’t lock a gem to a specific version as that makes updating gems more difficult.In general, consider only locking the major Rails gems, such as rails, RSpec, and bootstrap-sass, as these are the ones that will likely have more involved upgrades. It’s not necessary to introduce the added complexity of the test accelerators when doing major library updates. Naturally, it’s an iterative process to get tests passing when updating gems. You can try updating the gems one by one until you get a test failure.Here’s an example of a fork and commit of the zeus-parallel_tests gem that loosened a gem dependency.You should typically prefer a rubygems version of a gem rather than a github version.