It went comparatively smooth for us. 2 to 3 was a nightmare, 3 to 4 wasn't too awful. Some of the things that bit us:

* Strong parameters means you're going to have to figure out what everything needs for params or break down and call permit! where acceptable. If anyone got crazy with attribute metaprogramming bullshittery, you're in for fun.

* The deep_munge part of strong parameters has some strong opinions about how it should do its job. The code is there to prevent attacks where unusual user input is handed directly to ActiveRecord and interpreted by it. One special case to look out for is that it will rewrite a (JSON-supplied) empty array into nil, which makes life fun if your API happens to put some semantic meaning on nil vs. empty arrays.

* The new restrictions on routing verbs are good stuff, but I can almost guarantee that something was getting away with using the wrong verb before.

* XML parameter parsing has been extracted to a plugin. For some reason XML generation wasn't, but if people are sending you XML data you'll need this: https://github.com/rails/actionpack-xml_parser

That's all I can think of off the top of my head.

In response to this:

> Does that mean I need to go through and rewrite all our models and controllers before we can update?

Not really, no. As a first step we rewrote all of our attr_accessible usage into model class-level constants we could run through strong_parameters. Eventually those moved out of the model, but it was good enough to get going. Example:

# Rails 3.2

class Foo < ActiveRecord::Base

  attr_accessible :name, :bar, :whatever

  attr_accessible :name, :bar, :whatever, :approved, :as => :admin

end

# Rails 4.0

class Foo < ActiveRecord::Base

  UPDATEABLE_ATTRIBUTES = [:name, :bar, :whatever]

  ADMIN_UPDATEABLE_ATTRIBUTES = UPDATEABLE_ATTRIBUTES + [:approved]

end

3.2 -> 4 is an order of magnitude easier than 2 -> 3.

The upgrade guide is pretty solid, and I imagine it mostly applies for Rails 4.1 as well: http://guides.rubyonrails.org/upgrading_ruby_on_rails.html#u...

I spent most of my time updating app config. For several of my 3.2 apps, I started using strong_parameters, so it wasn't a leap for me. Another app I have on 4.0 is using the https://github.com/rails/protected_attributes to retain the existing attr_accessible behavior until I get time to update.

Hope that helps!

It does not, you can actually pull in a gem[1] to use attr_accessible just fine with Rails 4. If you want to transition to strong_parameters, you can include the gem in your Rails 3 project and begin migrating to it, though that's a tough sell on most Rails codebases I've seen as it requires you to update every action in your app.

I have not personally migrated any of my code to Rails 4 from 3.2 yet but the transition will be far smoother than 2.3->3 was.

[1] - https://github.com/rails/protected_attributes

The railsdiff website is also a very handy little tool for quickly seeing the differences in config between versions:

http://railsdiff.org/diff/v3.2.17/v4.1.0/

Railsdiff.org just shows you what's changed in the generated app files, not the actual libraries.

Also be wary of your projects Gems, we just finished a 3.2 to 4.0 upgrade and though rails itself was pretty easy, there were quite a few problems with things such as Solr, Formtastic plugins (some FormTag internals changed in rails4, which broke some stuff).

So yea, the biggest problem was upgrading to Rails4 and getting the Gems to work- many of which had large structural changes in the Rails4 versions. For instance, Devise changed how they handle tokens in the Mailers, etc.

We have a very large App and it took us about 2 months part-time work to migrate fully to Rails4 - of that I'd say about 70-75% of the work was a combination of rewriting strong_parameters/attr_accessible stuff and updating/monkey patching Gems to get them working. But we did go really far, we removed all the stuff that generated deprecated warnings and removed all the "migration helper gems" like "protected_attributes". So if your project doesnt depend on many gems it could be really easy especially if you dont care about using the helper gems like protected_attributes until you get around to rewriting things.

Part of the motivation why we adopted a lib/hacks/ convention

Extracted here:

https://github.com/steakknife/rails41rc_plus_hacks_and_threa...

It's a way smoother upgrade - exactly as you mentioned really the only major change is from attr_accessible to strong parameters however you can still include the protected attributes gem for a quicker/easier upgrade path (https://github.com/rails/protected_attributes)

I'm not 100% sure, but I believe you can upgrade without a lot of rewriting by using the protected_attributes gem (https://github.com/rails/protected_attributes).

You are correct that attr_accessible is gone in favor of strong parameters.

Google fu yields http://stackoverflow.com/questions/17371334/how-is-attr-acce...

Depending on how your test suite is set up (if you have one) there may need to be some sweeping changes there. When we migrated we had to switch from our should syntax to the expect s syntax.

I can't remember anything else that was super crazy.

I'm working on an update too, and am biting the bullet and rewriting the strong_parameters/attr_accessible parts.

But, you can in theory use the Protected Attributes gem to aid migration with less rewrite.[1]

[1] http://edgeguides.rubyonrails.org/upgrading_ruby_on_rails.ht...

I recently upgraded a 3.2 application to 4.0. At a high level, the necessary refactoring to make 4.0 work wasn't bad. It was upgrading gem dependencies, and sometimes switching out deprecated gems, that was a much bigger pain.

My co-founder wrote a book on exactly this. In case you're interested: https://leanpub.com/upgradetorails4