开发者

Has anyone successfully deployed a Rails project with Ruby 1.9.1? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 10 years ago.

Last week I successfully completed the transition of all our company applications from Ruby 1.8.6 to Ruby 1.8.7 including local and remote configurations. From now on, development won't need to ensure backward-compatibility with Ruby 1.8.6.

For the sake of curiosity, I tried to run the test suite of a couple of projects against Ruby 1.9.1. As expected, I found some encoding-related i开发者_JS百科ssue but I was really shocked when I discovered low-level incompatibilities such as a Rack::Link known bug. At this point, the idea of moving development to Ruby 1.9.1 is simply not applicable.

I was wondering if anyone has successfully deployed a Rails project with Ruby 1.9.1. Which Ruby version do you use for your Rails projects? Are you planning to upgrade to a more recent version?


Matz recently spoke at RubyFoo in London about ruby 1.9.1 adoption. Quite simply, ruby 1.9.1 is not production ready and should not be used for deployment just yet.

Ruby 1.9.2 will be production ready, but until then you should only use ruby 1.9.1 for play and testing.

Although many people out there have had successful deployments using 1.9.1, I would recommend sticking with REE 1.8.7 until 1.9.2 is out. Rails 3.0 will favor 1.9.2, but also work quite happily with 1.8.7 (it will NOT work with 1.8.6).


Gitorious is a pretty large and complex Rails project with a large number of users. Gitorious runs fine on both Ruby 1.8 and Ruby 1.9, but the biggest Gitorious installation, which is Gitorious.Org itself, has been running exclusively on Ruby 1.9 and YARV for quite some time now. (At least since May, I think.)

And the best part is of course that it is not only Open Source but a truly Open Project with open mailinglist, open bugtracker and open repository, so that you can see exactly how they did it and how much work it was.


I spent a day looking at the feasibility of this and am going to wait a while longer.

As it stands you can get stuff to mostly work but there are some seriously scary workarounds you will have to put in place to get stuff going.

  1. The MySql gem (version 2.8.1) returns all strings in ASCII encoding, this means trouble cause when you start appending them in your views you get all sorts of nasty errors. There is a work around but it involves compiling the gem with patches see: Encoding problems in rails on ruby 1.9.1
  2. You need to force utf-8 encoding globally using hacks or env vars
  3. Passenger 2.2.7 has trouble due to a bug in Ruby tempfile, so you have to hack at the source: Ruby 1.9.1-p234, Passenger 2.2.5, Rails 2.3-stable closed stream on POST request
  4. Some gems just do not work at all.

As much as I would love the perf boost, I think it is a bit too bleeding edge at the moment, it is probably a good idea to wait till early mid 2010


No conversion to Ruby 1.9.1 done here. I tend to be conservative with upgrading. For production work I like to stick with the tried & tested stuff. Also, IMHO 1.9.1 is nice and making sure you keep you dependency versions up to date is a good habit. Developing on the bleeding edge can be painfull at times as you have noticed. It's safer to stay one version behind the bleeding edge if you don't want to run into these kind of issues.


Also no 1.9.1 here. As much as it makes me sick to say it, we'll just wait for 37signals to do it first.

Once those with commit rights do it, bugs will get resolved much faster.

0

上一篇:

下一篇:

精彩评论

暂无评论...
验证码 换一张
取 消

最新问答

问答排行榜