6 ms·

Rails 4.0: Release Candidate 1 released

173 points by jordn 13y ago

zachgersh 13y ago
Weird that the skipped out on Hartl Tutorial in their announcement, it's actually been in Beta for awhile: http://ruby.railstutorial.org/ruby-on-rails-tutorial-book?version=4.0#top http://ruby.railstutorial.org/ruby-on-rails-tutorial-book?ve...
- steveklabnik 13y ago
  Obviously, these lists aren't comprehensive: I have commit to Rails, am helping to write a book on Rails 4 [1], and it's not listed, either. ;) AWDWR is actually tested as part of each release,[2] so it obviously gets a big shout-out. 1: http://www.manning.com/bigg2/ http://www.manning.com/bigg2/ 2: https://github.com/rails/rails/blob/master/RELEASING_RAILS.rdoc#is-sam-ruby-happy--if-not-make-him-happy https://github.com/rails/rails/blob/master/RELEASING_RAILS.r...
  - zachgersh 13y ago
    We need to get your Rails 4 book up there then Steve :D I actually would love to see a comprehensive list, obviously can't all fit in this short release post!
    - steveklabnik 13y ago
      It's a little farther behind the others, Ryan had updated it for Rails 3.2, and I'm updating it for 4, and my editor and I are going over the first half of the book's updates now. AWDWR is already 100% updated (and I think CRA is too), so it makes sense that mine didn't get mentioned; it's hard to both work on Rails and work on writing a book on Rails.
- mhartl 13y ago
  Thanks for mentioning this. You're right that the beta book has been out for a while, and I've tried updating the Rails Tutorial for the release candidate as well, but the new RC breaks tons of tests in the sample application. I probably won't have time to figure out the cause of the breakage until after RailsConf is over, but I'll plan to get to this ASAP next week.
  - zachgersh 13y ago
    Love the book and so happy it is available (I am sure I speak for many others). If you need any help with the sample application please shoot me a message! Would be glad to pitch in some time.
steveklabnik 13y ago
This is a huge step forward to a big release! I myself built a little app with the RC, Ruby 2.0, and deployed it to Heroku yesterday, and that whole stack works just fine. _Please_ give the RC a try, and file any issues you have on the tracker: https://github.com/rails/rails/issues?state=open https://github.com/rails/rails/issues?state=open There's nothing more frustrating as a maintainer than getting regression reports the day after you release when you've done two or three RC releases. :( I'd be happy to answer any questions you have about the release either here or over email, as well.
- kawsper 13y ago
  Sorry for a potential stupid question: Is there an upgrade guide somewhere? I noticed that mperham mentioned on Twitter that he had 250+ bugs his test-suite after upgrading, and I am sure he and his team have better and more elaborate tests than me.
  - elektronaut 13y ago
    There is one here: http://edgeguides.rubyonrails.org/upgrading_ruby_on_rails.html#upgrading-from-rails-3-2-to-rails-4-0 http://edgeguides.rubyonrails.org/upgrading_ruby_on_rails.ht...
  - steveklabnik 13y ago
    As mentioned below, there is that official upgrade guide. It is not comprehensive, as mentioned in the post. Should get you going, though. We'll be continuing to work on it now that there's an RC out. I personally have reviewed (but am not getting a cut of) http://www.upgradingtorails4.com/ http://www.upgradingtorails4.com/ and it's pretty good.
  - ninthfrank07 13y ago
    I highly recommend watching these free videos from Code School: http://rails4.codeschool.com/videos http://rails4.codeschool.com/videos.
- mpd 13y ago
  The issue I keep running into when testing the RCs with larger apps is the number of gems that have strict dependencies on older versions of activesupport, etc. I am wading through my Gemfile (over 200 gems counting direct and indirect dependencies) at the moment trying to give the RC a shot, but it's going to be difficult to justify spending much more time on it, unfortunately.
shousper 13y ago
Hmm.. ~1 month out from starting alpha testing of my app, do I update now, or later. Decisions..
- chrismccord 13y ago
  If you're coming from 3.1 or 3.2, I say go for it. I have brought a couple applications from 3.2 -> 4.0rc and both had specs fully passing within 30 minutes of the switch. git checkout -b rails4, it won't hurt to try.
- jdminhbg 13y ago
  I would do it now; it's not going to get easier later. I personally have had good luck upgrading small apps very easily from 3.2->4.0. The main thing I've run into with larger apps is going from attr_accessible->strong_params, which I realize I could do simply by adding the gem, but I'd rather go whole hog on it.
  - nthj 13y ago
    > I would do it now; it's not going to get easier later. Rails 4 may be stable, but there are a thousand gems to still be brought up to speed. It very well may get easier later.
deleted 13y ago
[deleted]
6thSigma 13y ago
Would it be possible to get a TL;DR version of any decently sized changes from 4.0beta -> 4.0rc1?
- steveklabnik 13y ago
  In general, things were deprecated or moved to a gem, but it's intended to be compatible. Check the upgrading guide for a reasonable Tl;dr, I'm excited about strong_parameters and HTTP PATCH, personally.
purephase 13y ago
Are we going to see another 3.2 release outside of security issues? There have been enough performance and functionality related issues in 3.2.13 that I was hoping to see at 3.2.14.
- steveklabnik 13y ago
  Here's the maintenance policy: http://weblog.rubyonrails.org/2013/2/24/maintenance-policy-for-ruby-on-rails/ http://weblog.rubyonrails.org/2013/2/24/maintenance-policy-f... Tl;dr: after 4.0 is released, no. But bugfixes have been merged into 3-2-stable that there should be a 3.2.14 before the security-only releases start.
  - stiff 13y ago
    Wow, just one version beyond the most current one, this sucks so much, especially combined with the rather careless attitude about backwards compatibilty...
    - steveklabnik 13y ago
      We've made significant steps towards not having a 'careless attitude,' that blog post being one of them. Now the exact policy is spelled out. Another big one is the 'not deprecating something in z releases (of x.y.z)' policy, which should help too. Remember, Rails does not follow SemVer, so if you're expecting interface compatibility to line up with it exactly, you're gonna have a bad time. If we _had_ followed SemVer, you wouldn't see all those comments upthread about how this was 'the smoothest major upgrade ever', since in SemVer 3 -> 4 would mean no compatibility.
  - purephase 13y ago
    Thanks Steve.
dominotw 13y ago
I remember there was a time when rails releases meant extraction of working knowledge into the framework. Now it looks like they are just choosing to support frameworks which they think are the best.
- steveklabnik 13y ago
  Most of the features added to Rails 4 came directly out of David's work on making Basecamp Next fast. In fact, Rails 4 is so extracted from David's working knowledge that some people feel it's _too specific_, hence the whole "Omakase" thing a few months back. (I'd also note that your two sides aren't actually opposed: if you pull things out from 'working knowledge,' then you obviously think that they're the best. Both conditions can absolutely be true.)
ardiyu07 13y ago
Wow they're fast
jrochkind1 13y ago
> Rails 4.0 removed the assets group from Gemfile. You'd need to remove that line from your Gemfile when upgrading. Can anyone explain or provide a cite to more on this? What the intention is here, what one is supposed to do with gems only used in asset compilation but not needed in actual production app environment?
- steveklabnik 13y ago
  Two things: 1) Sprockets integration was totally re-written, with huge performance benefits. It's now sprockets-rails. 2) Before, to precompile, you did this: bundle exec rake assets:precompile Now, you do this: RAILS_ENV=production bundle exec rake assets:precompile I'm not sure of the details of what changed about this, but basically, it was that you did need assets in all environments anyway, so the group is no longer needed.
  - jrochkind1 13y ago
    Thanks for more details -- is this documented anywhere yet? If not, it might be good to add to the "docs needed" checklist. (Also, if when migrating an app from 3 to 4 you need to manually add 'sprockets-rails' to your Gemfile, should be mentioned in migration guide) It seems unfortunate to me that all those gems involved only in asset compiling now need to be in every environment -- meaning they need to actually be loaded and 'require'd in your production running app, even though assets have already been compiled. Hopefully that change to requirements was needed to reap some worthwhile benefit, it's still pretty sketchy to me why the sprockets integration improvements led to this change.
    - steveklabnik 13y ago
      I am not 100% sure. I'll talk to the people in charge of the asset pipeline and get it in there. > it's still pretty sketchy to me why the sprockets integration improvements led to this change. Sprockets is one of the parts of Rails I know least about, so yeah, I'm not sure why this decision was made. But explaining it somewhere for posterity is a good thing, absolutely.

173 points by jordn 13y ago

Weird that the skipped out on Hartl Tutorial in their announcement, it's actually been in Beta for awhile: http://ruby.railstutorial.org/ruby-on-rails-tutorial-book?version=4.0#top http://ruby.railstutorial.org/ruby-on-rails-tutorial-book?ve...

steveklabnik 13y ago
Obviously, these lists aren't comprehensive: I have commit to Rails, am helping to write a book on Rails 4 [1], and it's not listed, either. ;) AWDWR is actually tested as part of each release,[2] so it obviously gets a big shout-out. 1: http://www.manning.com/bigg2/ http://www.manning.com/bigg2/ 2: https://github.com/rails/rails/blob/master/RELEASING_RAILS.rdoc#is-sam-ruby-happy--if-not-make-him-happy https://github.com/rails/rails/blob/master/RELEASING_RAILS.r...
- zachgersh 13y ago
  We need to get your Rails 4 book up there then Steve :D I actually would love to see a comprehensive list, obviously can't all fit in this short release post!
  - steveklabnik 13y ago
    It's a little farther behind the others, Ryan had updated it for Rails 3.2, and I'm updating it for 4, and my editor and I are going over the first half of the book's updates now. AWDWR is already 100% updated (and I think CRA is too), so it makes sense that mine didn't get mentioned; it's hard to both work on Rails and work on writing a book on Rails.
mhartl 13y ago
Thanks for mentioning this. You're right that the beta book has been out for a while, and I've tried updating the Rails Tutorial for the release candidate as well, but the new RC breaks tons of tests in the sample application. I probably won't have time to figure out the cause of the breakage until after RailsConf is over, but I'll plan to get to this ASAP next week.
- zachgersh 13y ago
  Love the book and so happy it is available (I am sure I speak for many others). If you need any help with the sample application please shoot me a message! Would be glad to pitch in some time.

steveklabnik 13y ago

This is a huge step forward to a big release! I myself built a little app with the RC, Ruby 2.0, and deployed it to Heroku yesterday, and that whole stack works just fine. _Please_ give the RC a try, and file any issues you have on the tracker: https://github.com/rails/rails/issues?state=open https://github.com/rails/rails/issues?state=open There's nothing more frustrating as a maintainer than getting regression reports the day after you release when you've done two or three RC releases. :( I'd be happy to answer any questions you have about the release either here or over email, as well.

kawsper 13y ago
Sorry for a potential stupid question: Is there an upgrade guide somewhere? I noticed that mperham mentioned on Twitter that he had 250+ bugs his test-suite after upgrading, and I am sure he and his team have better and more elaborate tests than me.
- elektronaut 13y ago
  There is one here: http://edgeguides.rubyonrails.org/upgrading_ruby_on_rails.html#upgrading-from-rails-3-2-to-rails-4-0 http://edgeguides.rubyonrails.org/upgrading_ruby_on_rails.ht...
- steveklabnik 13y ago
  As mentioned below, there is that official upgrade guide. It is not comprehensive, as mentioned in the post. Should get you going, though. We'll be continuing to work on it now that there's an RC out. I personally have reviewed (but am not getting a cut of) http://www.upgradingtorails4.com/ http://www.upgradingtorails4.com/ and it's pretty good.
- ninthfrank07 13y ago
  I highly recommend watching these free videos from Code School: http://rails4.codeschool.com/videos http://rails4.codeschool.com/videos.
mpd 13y ago
The issue I keep running into when testing the RCs with larger apps is the number of gems that have strict dependencies on older versions of activesupport, etc. I am wading through my Gemfile (over 200 gems counting direct and indirect dependencies) at the moment trying to give the RC a shot, but it's going to be difficult to justify spending much more time on it, unfortunately.

shousper 13y ago

Hmm.. ~1 month out from starting alpha testing of my app, do I update now, or later. Decisions..

chrismccord 13y ago
If you're coming from 3.1 or 3.2, I say go for it. I have brought a couple applications from 3.2 -> 4.0rc and both had specs fully passing within 30 minutes of the switch. git checkout -b rails4, it won't hurt to try.
jdminhbg 13y ago
I would do it now; it's not going to get easier later. I personally have had good luck upgrading small apps very easily from 3.2->4.0. The main thing I've run into with larger apps is going from attr_accessible->strong_params, which I realize I could do simply by adding the gem, but I'd rather go whole hog on it.
- nthj 13y ago
  > I would do it now; it's not going to get easier later. Rails 4 may be stable, but there are a thousand gems to still be brought up to speed. It very well may get easier later.

deleted 13y ago

[deleted]

6thSigma 13y ago

Would it be possible to get a TL;DR version of any decently sized changes from 4.0beta -> 4.0rc1?

steveklabnik 13y ago
In general, things were deprecated or moved to a gem, but it's intended to be compatible. Check the upgrading guide for a reasonable Tl;dr, I'm excited about strong_parameters and HTTP PATCH, personally.

purephase 13y ago

Are we going to see another 3.2 release outside of security issues? There have been enough performance and functionality related issues in 3.2.13 that I was hoping to see at 3.2.14.

steveklabnik 13y ago
Here's the maintenance policy: http://weblog.rubyonrails.org/2013/2/24/maintenance-policy-for-ruby-on-rails/ http://weblog.rubyonrails.org/2013/2/24/maintenance-policy-f... Tl;dr: after 4.0 is released, no. But bugfixes have been merged into 3-2-stable that there should be a 3.2.14 before the security-only releases start.
- stiff 13y ago
  Wow, just one version beyond the most current one, this sucks so much, especially combined with the rather careless attitude about backwards compatibilty...
  - steveklabnik 13y ago
    We've made significant steps towards not having a 'careless attitude,' that blog post being one of them. Now the exact policy is spelled out. Another big one is the 'not deprecating something in z releases (of x.y.z)' policy, which should help too. Remember, Rails does not follow SemVer, so if you're expecting interface compatibility to line up with it exactly, you're gonna have a bad time. If we _had_ followed SemVer, you wouldn't see all those comments upthread about how this was 'the smoothest major upgrade ever', since in SemVer 3 -> 4 would mean no compatibility.
- purephase 13y ago
  Thanks Steve.

dominotw 13y ago

I remember there was a time when rails releases meant extraction of working knowledge into the framework. Now it looks like they are just choosing to support frameworks which they think are the best.

steveklabnik 13y ago
Most of the features added to Rails 4 came directly out of David's work on making Basecamp Next fast. In fact, Rails 4 is so extracted from David's working knowledge that some people feel it's _too specific_, hence the whole "Omakase" thing a few months back. (I'd also note that your two sides aren't actually opposed: if you pull things out from 'working knowledge,' then you obviously think that they're the best. Both conditions can absolutely be true.)

ardiyu07 13y ago

Wow they're fast

jrochkind1 13y ago

> Rails 4.0 removed the assets group from Gemfile. You'd need to remove that line from your Gemfile when upgrading. Can anyone explain or provide a cite to more on this? What the intention is here, what one is supposed to do with gems only used in asset compilation but not needed in actual production app environment?

steveklabnik 13y ago
Two things: 1) Sprockets integration was totally re-written, with huge performance benefits. It's now sprockets-rails. 2) Before, to precompile, you did this: bundle exec rake assets:precompile Now, you do this: RAILS_ENV=production bundle exec rake assets:precompile I'm not sure of the details of what changed about this, but basically, it was that you did need assets in all environments anyway, so the group is no longer needed.
- jrochkind1 13y ago
  Thanks for more details -- is this documented anywhere yet? If not, it might be good to add to the "docs needed" checklist. (Also, if when migrating an app from 3 to 4 you need to manually add 'sprockets-rails' to your Gemfile, should be mentioned in migration guide) It seems unfortunate to me that all those gems involved only in asset compiling now need to be in every environment -- meaning they need to actually be loaded and 'require'd in your production running app, even though assets have already been compiled. Hopefully that change to requirements was needed to reap some worthwhile benefit, it's still pretty sketchy to me why the sprockets integration improvements led to this change.
  - steveklabnik 13y ago
    I am not 100% sure. I'll talk to the people in charge of the asset pipeline and get it in there. > it's still pretty sketchy to me why the sprockets integration improvements led to this change. Sprockets is one of the parts of Rails I know least about, so yeah, I'm not sure why this decision was made. But explaining it somewhere for posterity is a good thing, absolutely.