Would love opinions from the HN gallery as to whether a delay now saves time later.
Edit: And thanks to the Rails team for providing me with this conundrum!
Edit2: Thanks for the info and opinions! I'll check back later too.
If you're on 2.3.x upgrade, otherwise wait a bit.
To the OP, I suggest you launch with 3.x and upgrade immediately after to 4 and start taking note of deprecations.
Yeah, but that pain will come regardless. Better I think to wait until the dust settles on turbolinks et al and plugin authors update. You could always update first to 4.0.x (for mild to large values of x) or what have you before jumping over to 4.1.
Point is, if you've got a large app it's not worth pushing back any deadlines. Someone's gotta do it! and much to love to the rails-core team, but being 3 months behind the release schedule still counts as "bleeding edge" in most of the rest of the software world ;).
I think this is the most likely outcome. Thanks again to everyone for the discussion too.
If anyone has gems that don't work with 4 yet, please let me know. Most of them at least have a branch going, but I'm always curious, and am willing to help out to upgrade things.
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...
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.
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!
Full disclosure: I'm friends and work with Andy and he's super smart and I'm not getting a kickback. :)
Nobody wanted a 2 -> 3 transition again.
For larger apps (which I maintain as a freelance) I would wait a bit more though, since some gems will still have little bugfixes related to Rails 4 compatibility, most likely.
If you see any failures in the days after upgrading you have a new variable to consider on the cause.
Look at what the best/worst outcomes are from making the change - does the risk justify the benefit?
Would I do it? yes probably, I can't sleep if I'm on a 3 when I know there is a 4 around.
In the meantime you can watch bug / experience reports and get some info to make an educated decision.