Ruby on Rails 4.0 も近いうちにリリースされると思いますが、Ruby on Rails 3.2 で作られたアプリは、そのまま動くのでしょうか？
互換性 vs 進歩
Ruby on Rails では 良いソフトになるのなら多少の互換性は犠牲にしても、良いソフトに進歩しようという指向があります。Ruby言語もRailsほど過激ではありませんが同じような指向はあると思います。
Java言語のように、互換性を重きを置きながらバージョンアップするソフトウェアもあります。たしかに、言語やフレームワークをバージョンアップしてもアプリがそのまま動くと言うことは、大きなメリットです。
しかし、いまやRubyを始めほとんどの言語が持つクロージャーの導入は Java 7で検討されましたが、結局 7 では見送られてしまいました。
有用な技術を導入するのに時間がかかりすぎるのは、言語やフレームワークとしての進化を遅くしてしまい、インターネット時代の速度感について行けないレガシーな技術に追いやられてしまう危険性を持っていると思います。
Ruby on Railsのバージョンアップ
Ruby on Railsで 3 から 4 に上がるようなメジャーバージョンアップの際には、従来のコードのうち、書き換えないと動かない部分が出来てきてしまいます。どうやってRuby on Railsを使ったシステムはバージョンアップに対応しているのでしょうか？
アップデート パス
Ruby on Railsでは廃止になる部分は、直ぐには無くなりません。Rails 4 ではいくつかの レガシーなAPIが廃止されますが、4.0 では警告が発生するだけで動作はします。そして次のバージョン 4.1 の時点でAPI等が削除されます。
したがって、開発者は Rails 4.0 のうちに、無くなるAPIの対応を行い、警告が無くなるのを確認すれば良く、対応には時間的な余裕があります。
ユニットテスト
Ruby on Railsで作られたシステムが頻繁なバージョンアップに付いて行ける秘密は、Ruby, Ruby on Rails開発者に定着しているユニットテストを書く文化にあります。
ユニットテストは、品質を保証するテストではありませんが、ユニットテストが通っているコードは動作の可能性を高く示してくれます。
また、ユニットテストはプログラムですから実行するだけで直ぐに結果がわかります、人手でアプリをテストするのに比べ圧倒的に時間も短く気軽に実施できます。
さらに、バージョンアップの為のコード修正による影響がプログラムの他の部分に出てないかなども確認でき、コード(システム)を健全に成長させてくれます。
