The upgrade isn't that bad. Nowhere near going 2.x to 3.x.
Definitely not going to be fun!
I have performed two rails 2 upgrades. Both cases they were smallish apps, but they took 3-5 days to feel comfortable with everything that's happened.
If this is an app that is still being actively developed, I highly recommend you fast track it.
[If not, look up the community-managed security back port branch and switch to that asap]
Basically, the problem stems from bit-rot and alas such is the nature of our industry. In a nutshell, the longer you wait the harder it is to find quality docs on what's changed and how to fix it. A lot of links are now gone.
The main challenge comes from: the change in the router, the changes in the view api (everything is escaped by default, and you will find a ton of string concats in your helpers that will now spit out garbage), migrating over to the asset pipeline (which I personally found confounding for a long time until I got the hang of it), migrating over to Arel queries and updating all of your plugins - many of which will stop working in quirky ways. You may also experience pain with updating your test suite.
So, there's a lot of yak shaving but you don't actually have to refactor your app much. Your controllers will remain basically untouched and so will your models modulo named scopes and certain now preferred validation patterns. Most of the pain is view-focussed.
Oh, and the attribute protection but that pain is a good pain, you really need to whitelist your attributes. IF YOU ARE READING THIS MAKE SURE YOUR MODELS HAVE AN `attr_accessible` THAT DOES NOT HAVE ANY ATTRIBUTE THAT ENDS IN `_id`.
There's a phenomenal plugin that will help a lot - https://github.com/rails/rails_upgrade - but it's not going to catch everything.
Suppose you have some kind of permissions model based around the department that a certain employee belongs to. Say, HR people can look at people's salaries.
If you allow mass assignment to department_id, someone can edit the form in the user page and assign themselves to ANY department and boom!, they're in.
You can fix this by having some sort of validation, but I find I prefer to have it in the controller.
Before:
@model.update_attributes(params[:model]) # trololol
dept = params[:model].delete[:department_id]
@model.update_attributes(params[:model])
if current_user.can(:foo)
@model.department = Department.find(dept)
end
You may be interested to know that you can have multiple attr_accessible declarations for different classes of user, and then when you call update_attributes you say which declaration should apply. But perhaps with strong parameters it's not worth going down that road.
We have actually backported sprockets/asset pipeline quite awhile back and have been using it without any major problems.
Definitely aware of the benefits its just very hard to do something at the scale that we're at :). Earlier this year our REE -> 1.9.3 upgrade took about a month and a half. For the past year we've been moving to separate, smaller applications and then breaking those into mountable engines within each application.
Appreciate the feedback though and the links!
Really, it's not large. The things I'm most worried about are
gem 'carrierwave'
gem 'jquery-fileupload-rails'
gem 'jquery-datatables-rails'
gem 'jquery-ui-rails'
I don't have a good answer: Fine to program with, but certainly took some doing for our particular need. (We had a number of requirements that made the "easy" out-of-the-box jquery-fileupload not suitable.)
Ask me in a couple of months and I'll probably have a lot of opinions to give.
> and when I saw there was some weird iframe thing for IE... I closed the page and walked away.
We are migrating customers from a C++ desktop app to a web interface: So anyone on old IE with problems will be informed that they're not supported on the new system, so keep using the old and let us know after they upgrade. :) (Newer IE is OK.)
Deviously, this also prevents absolutely everyone from ditching the old app and swamping the new system on day 1.
The iframe transport method for uploads is useful for browsers that don't support XHR file uploads (basically IE < 10). You can read more a bit about how it works in: https://github.com/blueimp/jQuery-File-Upload/wiki/Frequentl... or directly in the source: https://github.com/blueimp/jQuery-File-Upload/blob/master/js... (it's pretty small).
You'll have a bit of work to do to migrate to strong parameters, but you can always add the protected_attributes gem back to re-enable support for attr_accessible.
I'd suggest checking out the Rails 4 migration RailsCast.
I'm in the same boat (having been building on Rails 3 for a good while) and for now I'm going to stay put. People who are more knowledgeable about the specific updates please correct me if my assumptions are off-base.
- the bug fixes will only be included in 4.0.z releases
- the security issues will only be fixed in 4.0.z and 3.2.z
- the severe security issues will only be fixed in 4.0.z, 3.2.z
So you will want at least to upgrade to 3.2.z, or use Rails LTS ([2])
[1] http://weblog.rubyonrails.org/2013/2/24/maintenance-policy-f...