9 ms·

The upgrade isn't that bad. Nowhere near going 2.x to 3.x.

by jeremymcanally 13y ago

thibaut_barrere 13y ago
I definitely agree, this is a lot less difficult.
- dkrich 13y ago
  This would in many ways seem to suggest a less urgent need to upgrade from 3 to 4 than there was from 2 to 3 though. It seems like a major focus of 4 was speeding up client/server interactions. If that's not a major concern, I don't necessarily think it's something to lose sleep over in the near term. 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.
  - thibaut_barrere 13y ago
    Make sure to read the maintenance policy [1]: starting from today: - 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-for-ruby-on-rails/ http://weblog.rubyonrails.org/2013/2/24/maintenance-policy-f... [2] http://railslts.com/ http://railslts.com/
psychometry 13y ago
Depends on the size of your Gemfile. There will inevitably be gems that have unpatched Rails 4 bugs.
- jpdoctor 13y ago
  > Depends on the size of your Gemfile. 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' All of those 1. I don't understand their guts too well, and 2. if they fail then our target audience will hate us and hunt us down with pitchforks.
  - davidw 13y ago
    As an aside, how is the jquery-fileupload thing? I was reading about it, and when I saw there was some weird iframe thing for IE... I closed the page and walked away. That kind of thing looks like it could be a nightmare if something goes wrong.
    - jpdoctor 13y ago
      > As an aside, how is the jquery-fileupload thing? 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.
    - ebiester 13y ago
      Unfortunately, that's the necessary hack, as far as I know, if you want to have an ajax submission.
    - fbuilesv 13y ago
      Having recently worked with this project I can say that it's pretty reliable and way better than most jQuery plugins you'll find out there. 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/Frequently-Asked-Questions#why-is-the-file-input-field-cloned-and-replaced-after-each-selection https://github.com/blueimp/jQuery-File-Upload/wiki/Frequentl... or directly in the source: https://github.com/blueimp/jQuery-File-Upload/blob/master/js/jquery.iframe-transport.js https://github.com/blueimp/jQuery-File-Upload/blob/master/js... (it's pretty small).
  - sc00ter 13y ago
johnbellone 13y ago
Our application is still on 2.x and we were delaying migrating in hopes that we would have time to actually just refactor into a 3.x application. So this effectively means that we are going to either need to fast track this effort which is likely not going to happen, or make the attempt to migrate to 3.x with an application the size of an elephant. Definitely not going to be fun!
- phillmv 13y ago
  Hello! 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 https://github.com/rails/rails_upgrade - but it's not going to catch everything.
  - pjungwir 13y ago
    I'm a stickler for attr_accessible, but I've never heard of avoiding _id attributes. If a have an Employee model, what is wrong with `attr_accessible :department_id` (assuming I want to permit changing the department)?

The upgrade isn't that bad. Nowhere near going 2.x to 3.x.

thibaut_barrere 13y ago

I definitely agree, this is a lot less difficult.

dkrich 13y ago
This would in many ways seem to suggest a less urgent need to upgrade from 3 to 4 than there was from 2 to 3 though. It seems like a major focus of 4 was speeding up client/server interactions. If that's not a major concern, I don't necessarily think it's something to lose sleep over in the near term. 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.
- thibaut_barrere 13y ago
  Make sure to read the maintenance policy [1]: starting from today: - 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-for-ruby-on-rails/ http://weblog.rubyonrails.org/2013/2/24/maintenance-policy-f... [2] http://railslts.com/ http://railslts.com/

psychometry 13y ago

Depends on the size of your Gemfile. There will inevitably be gems that have unpatched Rails 4 bugs.

jpdoctor 13y ago
> Depends on the size of your Gemfile. 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' All of those 1. I don't understand their guts too well, and 2. if they fail then our target audience will hate us and hunt us down with pitchforks.
- davidw 13y ago
  As an aside, how is the jquery-fileupload thing? I was reading about it, and when I saw there was some weird iframe thing for IE... I closed the page and walked away. That kind of thing looks like it could be a nightmare if something goes wrong.
  - jpdoctor 13y ago
    > As an aside, how is the jquery-fileupload thing? 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.
  - ebiester 13y ago
    Unfortunately, that's the necessary hack, as far as I know, if you want to have an ajax submission.
  - fbuilesv 13y ago
    Having recently worked with this project I can say that it's pretty reliable and way better than most jQuery plugins you'll find out there. 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/Frequently-Asked-Questions#why-is-the-file-input-field-cloned-and-replaced-after-each-selection https://github.com/blueimp/jQuery-File-Upload/wiki/Frequentl... or directly in the source: https://github.com/blueimp/jQuery-File-Upload/blob/master/js/jquery.iframe-transport.js https://github.com/blueimp/jQuery-File-Upload/blob/master/js... (it's pretty small).
- sc00ter 13y ago

johnbellone 13y ago

Our application is still on 2.x and we were delaying migrating in hopes that we would have time to actually just refactor into a 3.x application. So this effectively means that we are going to either need to fast track this effort which is likely not going to happen, or make the attempt to migrate to 3.x with an application the size of an elephant. Definitely not going to be fun!

phillmv 13y ago
Hello! 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 https://github.com/rails/rails_upgrade - but it's not going to catch everything.
- pjungwir 13y ago
  I'm a stickler for attr_accessible, but I've never heard of avoiding _id attributes. If a have an Employee model, what is wrong with `attr_accessible :department_id` (assuming I want to permit changing the department)?