What is the core team thinking about moving to Rails 4? I am not super familiar with the entire Discourse codebase, but I don’t remember seeing much in the way of caching. Rails 4 has russian-doll caching, which I think would be very useful. Would it make sense to run on the betas releases of Rails 4 since Discourse is itself still in beta?
Personally I want to wait until a point release or two on Rails 4.
I heard on Twitter there are currently serious https issues in Rails 4, for example.
I doubt there are any problems running Discourse under Rails 4, I would love to move to it sooner rather than later.
If we could show that the simple test I ran here: Tuning Ruby and Rails for Discourse is much faster under Rails 4 it would be a huge push to get us to move to 4 for RC.
That said, clearly we will not move to 4.0 during beta, and I agree it may make sense to wait a month or 2 after RC. Nonetheless, I have a couple of hacks I would really like to erase out of the code base (one 4.0 backport and one 3 monkey patch that may go away in 4.0 if my PR is ever reviewed
I remember the Rails 3.0 branch wasn’t all that great at the beginning, Arel underperforming etc … so jumping on the first release of Rails 4 might not be the best idea.
Also, for the russian doll caching, it can be done in Rails 3 actually, just using the
touch option on associations …
Here’s a quick article talking about it How key-based cache expiration works – Signal v. Noise
The way I see it, it is a far less “breaky” release of rails, compared to the 2/3 HUGE move. I would like us there sooner rather than later.
I’d wait a couple weeks, then upgrade. We’ve got a 3.2.x bugfix release coming up soon. After that, I’d transition to 4.0. I suspect we’ll have 4.0 out in the next few months.
I am really hoping to get us to Rails 4 earlier rather than later, I would like us upgraded to Rack 1.5 so I can amend the message bus to use the new hijack API if the async api is not there for long polling (hijack is now implemented in unicorn and passenger --pre).
It seems Rack 1.5 is not going to happen in the 3.2 branch Relax Rack dependency by voxik · Pull Request #9488 · rails/rails · GitHub
Only side effect is that you can’t do connection keep alive with hijack (not a real problem for us as we can handle that in haproxy - in theory)
I had a quick look today and there are a number of gems that are still sort of broken in 4.0rc the biggest problems we have are
acts-as-paranoid has an open PR for support, I can not find anything for
sass-rails is supposed to work but for some reason is not.
I don’t believe you need to upgrade to Rails 4 to use the hijack API. The hijack API is an API provided by the app server, not by the rack gem. You can just bypass Rails for the URLs that you wish to use the hijack API on, e.g. by using a middleware on the top of the stack.
I have not tested passenger, but I tried unicorn and could not see [‘rack.hijack’] in the Rack env unless it was running on 1.5 or up, the app server in that case is not injecting it if it detects an earlier rack.
Phusion Passenger always provides the hijack API regardless of the Rack gem version.
As a side note, and especially if it will help development, I think you should dump the use of
acts-as-paranoid for the reasons I outline here. I really think it’s a useless gem that gets in your way more than actually helping.
I really delike that gem and vestal versions for that matter, in general I don’t like injecting behavior in monkey patches.
Would you care to attempt a PR to remove it?
Sure, I’ll take a shot at it. Is your test suite up to date and passing (i.e. can I rely on it) on the current version of the master branch?
Yes, it sure is, we also have travis hooked up and run smoke tests here
Excellent. I’ll get started.
I would much rather do this in stages, move to Ruby 2.0 first since it has clear performance advantages, then once that is stable for say a month, see if Rails has any point releases before going to 4.0. As @tenderlove said “we’ll have 4.0 out in the next few months” so really why the rush?
I don’t want to move to it before 4.0 is officially released, but do want to make sure some prep work is done. The big win is running these GCs out of band which would give us a big perf boost.
Agree moving our prd servers to Ruby 2.0 is a great place to start. Also want to make sure we test earlier on 4.0 to give the rails team time to fix any regressions or perf issues we find.
The biggest hurdle in upgrading to Rails 4 is not going to be the changes in Rails itself…
I recently tried upgrading a project of mine to Rails 4 and had to give up after a lot of my dependencies were either outright incompatible, or were coded with direct dependencies on Rails 3 features (particularly around ActiveRecord.)
It might be worth while to start the effort (considering how many gems we have in Gemfile.lock) and keep it at till we finally take a plunge.
The discovery involved in doing this in a big bang might be off putting.
I have a Rails 4 branch it is sort of working:
Quite a few gems need coercing, there are a few glitches in Rails as well to address, biggest one was: Can not specify multiple roots in Rails 4 · Issue #10494 · rails/rails · GitHub
But there are open issues such as:
- image_url on topic was bust, no idea why, have not debugged
- test suite needs to run
- spork is bust
In other news we no longer use acts_as_paranoid … this is simpler
Though I do seem to be going for some sort of record for workarounds per LOC
I helped move across a bunch or our models to Rails4 and Ruby 2. Most of the effort went into rewriting scopes. Chained scopes began behaving differently - although this seems to be an issue with 3.2.13 as well (see Github’s write up)
Also found these posts really helpful: