2. Changes

Application configuration is more friendly. config/environment.rb and config/environments/* are no longer littered with obscure options and Rails-specific initialization code. They are purely for your configuration.

The new config/environment.rb has about a dozen lines of configuration options with their defaults commented out. These config.option lines are specified within the Rails initializer, a new class which manages your application’s configuration, loading, and startup.

The new config/environments/*.rb follow this lead: each is a handful of configuration options which are evaluated within the Rails initializer.

Some utilities, such as Rake, don’t always need your entire application and the Rails framework to perform their tasks, so loading the heavyweight config/environment.rb is unnecessary. Enter config/boot.rb, just the barest essentials to set your app’s load path and load the Rails initializer. You should never need to edit boot.rb (it’s only 8 lines), but it’s worth knowing that it’s there.

Like config/environment.rb, the heavyweight Rakefile has been refactored into smaller sets of tasks which are built in to Rails, paring the old 180 lines down to a svelte 6.

The new Rakefile automatically includes lib/tasks/*.rake. If you have modified your Rakefile, move your changes to a file with the .rake extension in the lib/tasks directory.

Two defaults which affect the way your tests are run have changed in Rails 1.0: transactional fixtures have switched on and instantiated fixtures have switched off. These settings vastly improve test speed, particularly if your tests use many fixtures.

However, if your application relies on the old defaults, upgrading to 1.0 will break your tests. Test methods which use fixture instance variables like @jamis must use the fixture reader method people(:jamis).

Thankfully, you can get a head start on 1.0 by preparing your 0.13.1 application now. Set self.use_instantiated_fixtures = false and self.use_transactional_fixtures = true in test/test_helper.rb, get your tests passing, and you’re one step closer to a painless upgrade.

Mike Clark has written an excellent article on how and why these changes affect you.

The executable scripts in your application’s scripts directory are now stubs which delegate to Rails, so the next time you upgrade Rails you’ll get the new scripts without modifying your application at all.