5 ms·

Ug. We have a new website that is coming out in about a month. Enough mileage on 3.2 that it's too painful to consider delaying, but hate the thought of doing

Ug. We have a new website that is coming out in about a month. Enough mileage on 3.2 that it's too painful to consider delaying, but hate the thought of doing the upgrade later. 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.

thibaut_barrere 13y ago
I did a git branch for my app (https://www.wisecashhq.com/ https://www.wisecashhq.com/) - in 3 hours or so I was able to pass the tests and run the app properly. 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.
jeremymcanally 13y ago
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.
- 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)?
mtkd 13y ago
Good things rarely come from making radical changes at the last minute. 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.
- sigzero 13y ago
  I am the same way. I think it is "version OCD". lol
phillmv 13y ago
Having played this game repeatedly, I suggest waiting until 4.1 or so. Point releases are often buggier than intended, such is life, and it's going to take another year before plugins start requiring it anyways. If you're on 2.3.x upgrade, otherwise wait a bit.
- look_lookatme 13y ago
  I think Rails 4.1 is when all current deprecations are being removed, which is going to be a bit hairy for people accustom to <= Rail 3.x finder syntax and ancient plugins that somehow manage to still work. To the OP, I suggest you launch with 3.x and upgrade immediately after to 4 and start taking note of deprecations.
  - phillmv 13y ago
    >which is going to be a bit hairy for people accustom to <= Rail 3.x finder syntax and ancient plugins that somehow manage to still work. 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 ;).
  - jpdoctor 13y ago
    > To the OP, I suggest you launch with 3.x and upgrade immediately after to 4 and start taking note of deprecations. I think this is the most likely outcome. Thanks again to everyone for the discussion too.
  - rhizome 13y ago
    Last time we went through this, I wrote one app in 3.0, got a sense of the deprecations, started another at 3.1, then did straight 2>3 updates or new apps in 3.2 once I had it all down. There's no hurry.
- 13y ago
jonathanwallace 13y ago
There's at least two books I know of that cover upgrading to rails 4. Here's one: http://www.upgradingtorails4.com/ http://www.upgradingtorails4.com/ Full disclosure: I'm friends and work with Andy and he's super smart and I'm not getting a kickback. :)
steveklabnik 13y ago
The intention is for 4.0 to be as close to drop-in as reasonably possible, obviously, if you use some of the removed features, you'll need to add some gems to your gemfile. As is now normal with big Rails releases, 4.0 mostly deprecates, 4.1 will remove. Nobody wanted a 2 -> 3 transition again.
awj 13y ago
Is there something in Rails 4 that you desperately need? If not, wait. This looks like it will be a smother release than 2.x to 3.x was, but I wouldn't add this variable to the whole process this late in the game. In the meantime you can watch bug / experience reports and get some info to make an educated decision.

thibaut_barrere 13y ago

I did a git branch for my app (https://www.wisecashhq.com/ https://www.wisecashhq.com/) - in 3 hours or so I was able to pass the tests and run the app properly. 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.

jeremymcanally 13y ago

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.
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)?

mtkd 13y ago

Good things rarely come from making radical changes at the last minute. 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.

sigzero 13y ago
I am the same way. I think it is "version OCD". lol

phillmv 13y ago

Having played this game repeatedly, I suggest waiting until 4.1 or so. Point releases are often buggier than intended, such is life, and it's going to take another year before plugins start requiring it anyways. If you're on 2.3.x upgrade, otherwise wait a bit.

look_lookatme 13y ago
I think Rails 4.1 is when all current deprecations are being removed, which is going to be a bit hairy for people accustom to <= Rail 3.x finder syntax and ancient plugins that somehow manage to still work. To the OP, I suggest you launch with 3.x and upgrade immediately after to 4 and start taking note of deprecations.
- phillmv 13y ago
  >which is going to be a bit hairy for people accustom to <= Rail 3.x finder syntax and ancient plugins that somehow manage to still work. 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 ;).
- jpdoctor 13y ago
  > To the OP, I suggest you launch with 3.x and upgrade immediately after to 4 and start taking note of deprecations. I think this is the most likely outcome. Thanks again to everyone for the discussion too.
- rhizome 13y ago
  Last time we went through this, I wrote one app in 3.0, got a sense of the deprecations, started another at 3.1, then did straight 2>3 updates or new apps in 3.2 once I had it all down. There's no hurry.
13y ago

jonathanwallace 13y ago

There's at least two books I know of that cover upgrading to rails 4. Here's one: http://www.upgradingtorails4.com/ http://www.upgradingtorails4.com/ Full disclosure: I'm friends and work with Andy and he's super smart and I'm not getting a kickback. :)

steveklabnik 13y ago

The intention is for 4.0 to be as close to drop-in as reasonably possible, obviously, if you use some of the removed features, you'll need to add some gems to your gemfile. As is now normal with big Rails releases, 4.0 mostly deprecates, 4.1 will remove. Nobody wanted a 2 -> 3 transition again.

awj 13y ago

Is there something in Rails 4 that you desperately need? If not, wait. This looks like it will be a smother release than 2.x to 3.x was, but I wouldn't add this variable to the whole process this late in the game. In the meantime you can watch bug / experience reports and get some info to make an educated decision.