9

先週、ローカルおよびリモート構成を含む、Ruby1.8.6からRuby1.8.7へのすべての会社のアプリケーションの移行を正常に完了しました。今後、開発ではRuby1.8.6との下位互換性を確保する必要はありません。

好奇心のために、Ruby1.9.1に対していくつかのプロジェクトのテストスイートを実行しようとしました。予想通り、エンコーディング関連の問題を見つけましたが、Rack :: Linkの既知のバグなど、低レベルの非互換性を発見したときは本当にショックを受けました。現時点では、開発をRuby1.9.1に移行するという考えはまったく当てはまりません。

誰かがRuby1.9.1でRailsプロジェクトを正常にデプロイしたかどうか疑問に思いました。RailsプロジェクトにはどのRubyバージョンを使用していますか？より新しいバージョンにアップグレードすることを計画していますか？

4

5 に答える 5

10

Matzは最近、ロンドンのRubyFooでRuby1.9.1の採用について話しました。簡単に言うと、ruby 1.9.1は本番環境に対応していないため、まだデプロイに使用しないでください。

Ruby 1.9.2は本番環境に対応しますが、それまでは、プレイとテストにruby1.9.1のみを使用する必要があります。

多くの人が1.9.1を使用して展開に成功していますが、1.9.2がリリースされるまでREE1.8.7を使用することをお勧めします。Rails 3.0は1.9.2を優先しますが、1.8.7でも非常にうまく機能します（1.8.6では機能しません）。

于 2009-11-03T15:28:49.947 に答える
5

Gitoriousは、非常に大規模で複雑なRailsプロジェクトであり、多数のユーザーがいます。GitoriousはRuby1.8とRuby1.9の両方で正常に動作しますが、最大のGitoriousインストールであるGitorious.Org自体は、かなり長い間、Ruby1.9とYARVでのみ実行されています。（少なくとも5月以降だと思います。）

そしてもちろん、最良の部分は、オープンソースであるだけでなく、オープンメーリングリスト、オープンバグトラッカー、オープンリポジトリを備えた真にオープンなプロジェクトであるため、彼らがどのように実行し、どれだけの作業を行ったかを正確に確認できます。

于 2009-11-03T17:01:22.937 に答える
2

私はこれの実現可能性を検討するために1日を過ごし、もう少し待つつもりです。

現状では、ほとんどの場合は動作させることができますが、動作させるには、いくつかの非常に恐ろしい回避策を講じる必要があります。

  1. MySql gem（バージョン2.8.1）は、すべての文字列をASCIIエンコーディングで返します。これは、ビューに文字列を追加し始めると、あらゆる種類の厄介なエラーが発生するという問題の原因を意味します。回避策はありますが、パッチを使用してgemをコンパイルする必要があります。以下を参照してください。ruby1.9.1のレールでのエンコードの問題
  2. ハックまたはenv変数を使用してutf-8エンコーディングをグローバルに強制する必要があります
  3. Passenger 2.2.7は、Ruby tempfileのバグが原因で問題が発生しているため、ソースをハックする必要があります：Ruby 1.9.1-p234、Passenger 2.2.5、Rails2.3-POSTリクエストで安定したクローズドストリーム
  4. 一部の宝石はまったく機能しません。

パフォーマンスブーストが大好きなのと同じくらい、現時点では少し最先端すぎると思います。2010年半ばまで待つのはおそらく良い考えです。

于 2009-12-06T11:49:17.360 に答える
1

また、ここには1.9.1はありません。それを言うのは気分が悪くなりますが、37signalsが最初にそれを行うのを待つだけです。

コミット権限を持つ人がそれを行うと、バグははるかに速く解決されます。

于 2009-11-03T15:01:48.037 に答える
1

ここではRuby1.9.1への変換は行われません。私はアップグレードを控えめにする傾向があります。制作作業では、試行錯誤したものに固執するのが好きです。また、IMHO 1.9.1は優れており、依存関係のバージョンを最新の状態に保つことは良い習慣です。お気づきのように、最先端での開発は時には痛みを伴うことがあります。この種の問題に遭遇したくない場合は、最先端のバージョンの1つ後ろにとどまる方が安全です。

于 2009-11-03T14:30:25.073 に答える