4 ms·

> Rails went on to release subsequent versions, each of which advocated doing a near rewrite of working code and obsoleted/broke many of the libraries in the ec

> Rails went on to release subsequent versions, each of which advocated doing a near rewrite of working code and obsoleted/broke many of the libraries in the ecosystem. We recently upgraded our huge monolithic Rails 3.2x application to Rails 4.0 About ~300 kloc, and several hundred models. Lots of libs, tons of gem dependencies, lots of assorted bits like Resque tasks, etc. It's big. The upgrade was pretty painless, and it was handled by our least experienced internal team. No major rewrites involved. Most of the pain was just the grunt work of adopting Rails 4's strong parameters. We could have continued using attr_accessible, but felt that switching to strong parameters would give us an easier path in the future. There was also some random pain involved by the need to update various "3rd-party" (i.e., not core Rails) gems, some of which introduced incompatibilities or other issues. But, this was relatively minor. We did not encounter a need for this "near rewrite" you speak of. Nothing was rewritten, and none of the changes were large. From what I've seen of Rails 5.x, it shouldn't pose a major problem either. Now, I've heard that Rails 1.x to 2.x or 2.x to 3.x did involve a lot of breakage. I think that's what you're thinking of, maybe?

grandalf 10y ago
> Rails 1.x to 2.x or 2.x to 3.x Yep. I stopped choosing Rails for new projects after 2.0 but inherited a few codebases with newer Rails subsequently. The problem is not necessarily just with Rails, it's that gem authors don't necessarily have the bandwidth to support high quality versions of a gem for both versions. So if a gem is coupled to Rails' inner workings (as many are -- some unnecessarily) there is added downside to not upgrading even if the older version is working fine. It does look like the APIs are finally stabilizing. I'd like to see Rails gravitate more toward a series of conventions defined by contracts, not abstracted away into implicit behaviors.

grandalf 10y ago

> Rails 1.x to 2.x or 2.x to 3.x Yep. I stopped choosing Rails for new projects after 2.0 but inherited a few codebases with newer Rails subsequently. The problem is not necessarily just with Rails, it's that gem authors don't necessarily have the bandwidth to support high quality versions of a gem for both versions. So if a gem is coupled to Rails' inner workings (as many are -- some unnecessarily) there is added downside to not upgrading even if the older version is working fine. It does look like the APIs are finally stabilizing. I'd like to see Rails gravitate more toward a series of conventions defined by contracts, not abstracted away into implicit behaviors.