Live data from Hacker News

Rails 4.0: Release Candidate 1 released

weblog.rubyonrails.org

41–50 of 58 posts

Re: Rails 4.0: Release Candidate 1 released

#43

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

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.

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

Re: Rails 4.0: Release Candidate 1 released

#44

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.

Here's the maintenance policy: 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.

Wow, just one version beyond the most current one, this sucks so much, especially combined with the rather careless attitude about backwards compatibilty...

Re: Rails 4.0: Release Candidate 1 released

#45

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 There's nothing more frustrating as a maintainer than getting regression reports the day after you release when you've done tw…

692 examples, 0 failures, on both 1.9.3 and 2.0. This was the smoothest major upgrade yet, with very helpful deprecation notices. Thanks for all the hard work.

I had many failures when I just updated rails (from an edge version a couple of weeks old) to rc1. When I did a full bundle update it picked up the latest rspec-rails (2.13.1 instead of 2.13.0) and everything passed again.

The errors were I think caused by a change in the separation of the tests so database state was leaking between them causing failures but I haven't investigated deeply.

In these sorts of situations I never know whether it is best to 'bundle update' everything and have less information about the source of any problems or just to 'bundle update rails' and not receive the compatibility fixes straight away. How do others do this?

[Edited to add detailed version information and last paragraph].

Re: Rails 4.0: Release Candidate 1 released

#46
> 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?

Re: Rails 4.0: Release Candidate 1 released

#47

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.

Here's the maintenance policy: 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.

Thanks Steve.

Re: Rails 4.0: Release Candidate 1 released

#48

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

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.

Re: Rails 4.0: Release Candidate 1 released

#49

Earlier quoted context omitted.

692 examples, 0 failures, on both 1.9.3 and 2.0. This was the smoothest major upgrade yet, with very helpful deprecation notices. Thanks for all the hard work.

I had many failures when I just updated rails (from an edge version a couple of weeks old) to rc1. When I did a full bundle update it picked up the latest rspec-rails (2.13.1 instead of 2.13.0) and everything passed again. The errors were I think caused by a change in the separation of the tests so database state was leaking between them causing failures but I haven't investigated deeply. In these sorts of situations…

In rspec-rails' case, that's because an error was caught after the beta1 release, and 2.13.1 introduced the fix.

Generally, I do this:

1) update everything, run `rake rails:update`, and run the tests. Hope this works. If not, figure out if the error is mine or a gem's.

2) If it's a gem's, try to lock it to the exact version I was using and repeat 1).

3) If that doesn't work due to version issues, investigate if the gem has some sort of preview support for rails 4.

4) if not, either send a pull request or an issue.

Re: Rails 4.0: Release Candidate 1 released

#50

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.

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

Post reply on HN