Starting the long road to migrate up to supported versions of Rails and gems. Currently on 3.2 and upgrading to 4.0. Noted that 4.0 “prefers” Ruby 2.0 so I left my Ruby on 2.0. Can’t just “bundle update rails” because it couldn’t find compatible versions of railties. Googled and discovered that instead of “bundle update rails” I should delete the gemfile.lock and “bundle install”. When I do that, it wants to load the latest versions of gems which in many cases are not compatible with Rails 4.0. So I’ve gone through one-by-one dealing with the “xxx requires Ruby Version >= 2.x”, trying to determine the appropriate version to lock the gem down to. I’m using the reverse dependencies in some cases and comparing to my old gemfile.lock to experimentally determine (e.g. guess and test) the right version of each gem.
Is there any better way to do this? I know that if I were just upgrading to the latest version of everything I could just do “bundle upgrade” but all advice I’ve gotten is to upgrade one minor Rails version at a time.
Yes, well I have one of those “big” codebases that are mentioned in the article (I’m already aware of the article), so I’m doing one minor version at a time, and the first minor version update is giving me fits. I can’t do “bundle update rails” because there are other gems that must be updated simultaneously (like RailTies). So I followed the alternative instruction which is to kill the gemfile.lock, do a bundle install and (not documented) pin the gem versions that are trying to update too far one by one until you have a working bundle.
I’m just wondering if there is an alternative. I’ve been working for a number of hours on this, I’ve got 18 gems pinned at the same version from my old gemfile.lock.