I am happy to announce that Rails 4.2.3.rc1 and 4.1.12.rc1 have been released.

If no regressions are found expect the final release this Thursday, on June 25, 2015.
If you find one, please open an issue on GitHub
and mention me (@rafaelfranca) on it, so that we can fix it before the final release.

CHANGES since 4.1.11

To view the changes for each gem, please read the changelogs on GitHub:

I am happy to announce that Rails 4.2.1.rc4 and 4.1.10.rc4 have been released.

There were found some regressions in the last release candidates so, following release process we are
releasing new release candidates.

If no regressions are found expect the final release this Tuesday, on March 17, 2015.
If you find one, please open an issue on GitHub
and mention me (@rafaelfranca) on it, so that we can fix it before the final release.

CHANGES since 4.1.9

To view the changes for each gem, please read the changelogs on GitHub:

I am happy to announce that Rails 4.2.1.rc3 and 4.1.10.rc3 have been released.

There were found some regressions in the last release candidates so, following release process we are
releasing new release candidates.

If no regressions are found expect the final release this Thursday, on March 5, 2015.
If you find one, please open an issue on GitHub
and mention me (@rafaelfranca) on it, so that we can fix it before the final release.

CHANGES since 4.1.9

To view the changes for each gem, please read the changelogs on GitHub:

I am happy to announce that Rails 4.2.1.rc2 and 4.1.10.rc2 have been released.

There were found some regressions in the last release candidates so, following release process we are
releasing new release candidates.

If no regressions are found expect the final release this Monday, on March 2, 2015.
If you find one, please open an issue on GitHub
and mention me (@rafaelfranca) on it, so that we can fix it before the final release.

CHANGES since 4.1.9

To view the changes for each gem, please read the changelogs on GitHub:

I am happy to announce that Rails 4.2.1.rc1 and 4.1.10.rc1 have been released.

If no regressions are found expect the final release this Wednesday, on February 25, 2015.
If you find one, please open an issue on GitHub
and mention me (@rafaelfranca) on it, so that we can fix it before the final release.

CHANGES since 4.1.9

To view the changes for each gem, please read the changelogs on GitHub:

As per our maintenance policy, the release of Rails 4.2.0 means bug fixes will only apply to 4-2-stable,
regular security issues to 4.2.x, 4.1.x, and severe security issues to 4.2.x, 4.1.x, and 3.2.x.
In addition to these already stated commitments, I agreed to also apply bug fixes to 4-1-stable
until the Rails 5 release.

As before, we will announce in a future blog post when we will drop bug fixes support
for Rails 4.1.

CHANGES since 4.0.12

To view the changes for each gem, please read the changelogs on GitHub:

I am happy to announce that Rails 4.1.9.rc1 and 4.0.13.rc1 have been released.

This is the first release of the year and it includes a lot of bug fixes. This will be also
the last release of 4.0 series as announced
in a previous blog post.

As per our maintenance policy, the release of Rails 4.2.0 means bug fixes will only apply to 4-2-stable,
regular security issues to 4.2.x, 4.1.x, and severe security issues to 4.2.x, 4.1.x, and 3.2.x.
In addition to these already stated commitments, I agreed to also apply bug fixes to 4-1-stable
until the Rails 5 release.

As before, we will announce in a future blog post when we will drop bug fixes support
for Rails 4.1.

If no regressions are found expect the final release this Tuesday, on January 6, 2015.
If you find one, please open an issue on GitHub
and mention me (@rafaelfranca) on it, so that we can fix it before the final release.

CHANGES since 4.0.12

To view the changes for each gem, please read the changelogs on GitHub:

We come bearing gifts! It's Rails 4.2, and the final version is ready just in time for Christmas. It's full of great toys, useful gizmos, and polished edges, courtesy of a fantastic community of merry elves who've been coding away with jolly glee for months.

This is probably also the most well-tested new major release of Rails in a long time. Through four betas and three release candidates, tons of people have helped ensure that regressions and bugs have been caught. Since the first beta, we have some 1600+ commits of spit and polish applied. So you have good reason to be excited!

To recap, here's a walkthrough of the major new goodies:

Active Job, ActionMailer #deliver_later

The headline feature for Rails 4.2 is the brand new Active Job framework, and its integrations. Active Job is an adapter layer on top of queuing systems like Resque, Delayed Job, Sidekiq, and more. You can write your jobs to Active Job, and they'll run on all these queues with no changes.

With an always-configured queue in place (though the default is just an inline runner), we can build on top of that where it makes sense. And the first place it makes sense is to send Action Mailer emails asynchronously. So we're introducing the #deliver_later method, which will do just that: Add your email to be sent as a job to a queue, so you don't bog down the controller or model. Voila!

The cherry on top is our new GlobalID library. It makes it easy to pass Active Record objects to jobs by serializing them in a generic form. This means you no longer have to manually pack and unpack your Active Records by passing ids. Just give the job the straight AR object, and it'll serialize it using GlobalID, and deserialize it at run time. So much easier!

Adequate Record

Aaron Patterson is always hunting for performance bounties in Rails, and with an improvement project called Adequate Record for Active Record, he's come up good. A lot of common queries are now no less than twice as fast in Rails 4.2! This is a great step forward for performance. While computers are constantly getting cheaper and performance is improving, nobody ever said "hey, get that free speed out of my framework". So there you go: Some free speed, buddy!

Web Console

Out of the wonderful Google Summer of Code for Rails campaign comes Web Console, which gives you a development console to inspect the state of affairs on all exception pages! It even allows you to jump between the different points in the backtrace, and you'll be able to inspect things right at that point.

Foreign Keys

Rails has long had a tumultuous relationship with foreign keys, but the drama days are now over. If you want to have foreign keys, you can have foreign keys, and Rails will still smile as it takes your order. The migration DSL gets add_foreign_key and remove_foreign_key and the standard schema.rb dumper will support maintaing these declarations. Foreign key support starts out as an exclusive to the MySQL and PostgreSQL adapters.

And so much more...

The above are just the highlights. We have many more goodies packed into this release than that. You can read a great summary in the release notes.

Maintenance consequences and Rails 5.0!

As per our maintenance policy, the release of Rails 4.2 means bug fixes will only apply to 4-2-stable, regular security issues to 4.2.x, 4.1.x, and severe security issues to 4.2.x, 4.1.x, and 3.2.x. In addition to these already stated commitments, the honorable Rafael França has agreed to also apply bug fixes to 4-1-stable. So everyone still on 4.1 and unable to move quickly can thank Rafael!

Rails 4.2 also marks the last big release in the 4.x series. With this release out, we're now working towards the big Rails 5.0! This means rails/master is now targeting 5.0.

Rails 5.0 will target Ruby 2.2+ exclusively. There are a bunch of optimizations coming in Ruby 2.2 that are going to be very nice, but most importantly for Rails, symbols are going to be garbage collected. This means we can shed a lot of weight related to juggling strings when we accept input from the outside world. It also means that we can convert fully to keyword arguments and all the other good stuff from the latest Ruby.

The release target for Rails 5.0 is currently Fall of 2015. So there's a while yet, but we're putting this out there for people to know, so gem maintainers and other Ruby implementations can know where we're going. We'll be working on putting out somewhat of a road map for the features when that's become a bit clearer.

Thanks to all and happy holidays!

It continues to be a pleasure and an honor to be involved with the amazing Ruby on Rails community – both contributors and users. The collaboration and resulting quality has never been better. Have a great holiday season and New Year's, and we'll see you all with more delicious releases in 2015!

The RC3 release includes a few more minor patches over RC2. You can refer to
the diff on Github for a full list of changes.

We would like to thank you again for assisting our team in testing the release
candidates. Please continue to report any issues you discovered to our
issue tracker and/or notify the maintainers of the relevant gems and
plugins.

So far, we still haven't identify any major regressions for this release,
meaning that we are still on track for our target to release the final version
of 4.2.0 before Christmas time.

The RC2 release includes some patches for a few minor issues that was reported
in the last week. It also includes some improvements to the documentation and
some enhancements that decreases the verbosity of the Active Job logs. You can
refer to the diff on Github for a full list of changes.

We would like to thank you again for assisting our team in testing the release
candidates. Please continue to report any issues you discovered to our
issue tracker and/or notify the maintainers of the relevant gems and
plugins.

If no other major issues are found, we expect to release the final version of
4.2.0 very soon, just in time for Christmas!

In particular, thanks to contributors who have assisted in testing the release
in their Real World™ applications, we have identified and addressed a number of
performance issues since the last beta release.

With the release candidate out the door, we are now much closer to the final
release of 4.2.0. Please consider testing this release with your applications if
you haven't already – you can read the upgrade guide for
detailed instructions. If you found any problems while upgrading, please report
them to our issue tracker and/or notify the authors of the relevant
gems and plugins.

Thank you all again, this release would not be possible without your help!

These two releases contain only security fix that was already released as 4.0.12 and 4.1.8.
You can read more about the issue here (CVE-2014-7829).

4.0.12 and 4.1.8 were inadvertently based on their respective stable branches, and so incorporated
additional changes beyond those necessary to resolve the security issue. In keeping with our security
policy, it is our intention to include only the minimum necessary changes in security releases, to
ensure everyone can upgrade without fear of regressions. As those releases included unrelated changes,
we are providing new releases, based on the previous release, which contain only the security fix
itself.

If you have already successfully upgraded to 4.0.12 or 4.1.8, no further action is required.
Otherwise, if you are still on 4.0.11 or 4.1.7, please do upgrade to 4.0.11.1 or 4.1.7.1 at your
earliest convenience.

The 3.2.21 release did incorporate a second change, but that change was intended: by policy, minor
security-relevant bugs (which do not independently warrant a security release) are occasionally
backported to 3-2-stable, and rolled into a subsequent security release.

The commits for 4.0.11.1 can be found here,
and the commits for 4.1.7.1 can be found here.

I would like to announce that Rails 3.2.21, 4.0.12, and 4.1.8 have been released. These releases contain a security fix where the existence of arbitrary files on the file system can be leaked, but the contents of the file will not be leaked. The issue generally only impacts people who are using Rails to serve static assets, and will generally not impact people who use a proxy to serve static assets. This issue is similar to CVE-2014-7818, but is slightly different. You can read more about the issue here (CVE-2014-7829).

For ease of upgrading, the only changes in these releases are the security fixes.

In addition to the security fixes in 4.2.0.beta3,
this new release includes a number of bug fixes for issues reported since the
4.2.0.beta2 release.

If all goes according to plan, this should be the last beta release for 4.2.0
before we move into the Release Candidates phase. We would like to thank all
of the early adopters who participated in the beta testing and reported issues,
as well as the 64 contributors who submitted patches to help our team address
these bugs.

I would like to announce that Rails 3.2.20, 4.0.11, 4.1.7, and 4.2.0.beta3 have been released. These releases contain a security fix where the existence of arbitrary files on the file system can be leaked, but the contents of the file will not be leaked. The issue generally only impacts people who are using Rails to serve static assets, and will generally not impact people who use a proxy to serve static assets. You can read more about the issue here (CVE-2014-7818). A release of sprockets has also been made to help with this issue. You can read about it here (CVE-2014-7819).

For ease of upgrading, the only changes in these releases are the security fixes.

Today the Rails team is happy to announce that we have released Rails
4.2.0.beta2.

Thanks to all the early adopters who have participated in the first round of
beta testing, we have identified a number of bugs, regressions and other
imperfections in the codebase. These problems have since been fixed and included
in this release.

Security Issues

This release also includes two security patches.

Web Console 2.0.0.beta4

Along with the Rails 4.2.0.beta2 release we also released Web Console 2.0.0.beta4
which includes a security fix.

If you are already using Web Console in development we recommend you to upgrade
to this new version of the gem.

Active Job vulnerability

We also fixed an Active Job bug that allowed String arguments to be deserialized
as if they were Global IDs, an object injection security vulnerability.

Breaking Changes

In addition to the security and bug fixes, some of the new APIs have also been
refined after further testing in real-world applications. This resulted in the
following list of breaking changes that are not backwards-compatible with
4.2.0.beta1:

Active Job

The Active Job API has been overhauled:

# The enqueueing method has changed from +enqueue+ to +perform_later+.
#
# In 4.2.0.beta1:
MyJob.enqueue(*args)
#
# In 4.2.0.beta2:
MyJob.perform_later(*args)
# The ways jobs are scheduled has changed.
#
# In 4.2.0.beta1:
MyJob.enqueue_at(Date.tomorrow.noon, record)
MyJob.enqueue_in(1.week, record)
#
# In 4.2.0.beta2:
MyJob.set(wait_until: Date.tomorrow.noon).perform_later(record)
MyJob.set(wait: 1.week).perform_later(record)
#
# You can also specify a queue to enqueue the job onto with this new API:
MyJob.set(queue: :low_priority).perform_later(record)

Action Mailer

The Action Mailer API has also undergone some changes:

# Two new methods +#deliver_now+ and +#deliver_now!+ were introduced for
# clarity. +#deliver+ and +#deliver!+ have been deprecated and applications are
# encouraged to use the +#deliver_*+ instead.
#
# In 4.2.0.beta1:
Notifier.welcome(User.first).deliver!
#
# In 4.2.0.beta2:
Notifier.welcome(User.first).deliver_now!
# The options for +#deliver_later+ and +#deliver_later!+ has changed to match
# those on Active Job.
#
# In 4.2.0.beta1:
Notifier.welcome(User.first).deliver_later!(in: 1.hour)
Notifier.welcome(User.first).deliver_later!(at: 10.hours.from_now)
#
# In 4.2.0.beta2:
Notifier.welcome(User.first).deliver_later!(wait: 1.hour)
Notifier.welcome(User.first).deliver_later!(wait_until: 10.hours.from_now)

Action Controller render behavior change

Historically, calling render "foo/bar" in a controller action is equivalent
to calling render file: "foo/bar". Since beta 2, this has been changed to mean
render template: "foo/bar" instead. This is due to a number of potential
security issues with the old default behavior. If you need to render a file,
please change your code to use the explicit form (render file: "foo/bar")
instead.

Full list of changes

As always, you can browse the Rails source code repository on GitHub to view the
full list of changes
that were included in this release.

Acknowledgement

The Rails team would like to thank the 66 people who contributed patches to make
this release possible!

I am happy to announce that Rails 4.1.6 and 4.0.10 have been released.

We are planning to produce one more bug fix release in the 4.0 series, targeted for early December.
In keeping with our maintenance policy, after the upcoming release of 4.2.0, the 4.0 series will be
retired. It will not receive further updates for either bug fixes or security issues. All users are
urged to migrate to 4.1 as soon as possible.

CHANGES since 4.0.9

To view the changes for each gem, please read the changelogs on GitHub:

I am happy to announce that Rails 4.1.6.rc2 and 4.0.10.rc2 have been released.

If no regressions are found expect the final release this Thursday, on September 11, 2014.
If you find one, please open an issue on GitHub
and mention me (@rafaelfranca) on it, so that we can fix it before the final release.

CHANGES since 4.0.9

To view the changes for each gem, please read the changelogs on GitHub:

We're putting the final touches on the first major new release of Rails in its second decade of life. While most software would be in a retirement home after a decade of operation, Rails has never been more fit, and this release is packed with goodies that'll make your work even easier, your apps even faster, and the whole experience even better.

Active Job, ActionMailer #deliver_later

The headline feature for Rails 4.2 is the brand new Active Job framework, and its integrations. Active Job is an adapter layer on top of queuing systems like Resque, Delayed Job, Sidekiq, and more. You can write your jobs to Active Job, and they'll run on all these queues with no changes.

With an always-configured queue in place (though the default is just an inline runner), we can build on top of that where it makes sense. And the first place it makes sense is to send Action Mailer emails asynchronously. So we're introducing the #deliver_later method, which will do just that: Add your email to be sent as a job to a queue, so you don't bog down the controller or model. Voila!

The cherry on top is our new GlobalID library. It makes it easy to pass Active Record objects to jobs by serializing them in a generic form. This means you no longer have to manually pack and unpack your Active Records by passing ids. Just give the job the straight AR object, and it'll serialize it using GlobalID, and deserialize it at run time. So much easier!

Adequate Record

Aaron Patterson is always hunting for performance bounties in Rails, and with an improvement project called Adequate Record for Active Record, he's come up good. A lot of common queries are now no less than twice as fast in Rails 4.2! This is a great step forward for performance. While computers are constantly getting cheaper and performance is improving, nobody ever said "hey, get that free speed out of my framework". So there you go: Some free speed, buddy!

Web Console

Out of the wonderful Google Summer of Code for Rails campaign comes Web Console. It's an IRB console available in the browser. In development mode, you can go to /console and do your work right there.

Now that's neat, but what's insanely useful is that this console is automatically available on all exception pages! So when something is bust, you'll now instantly be able to inspect the state of affairs. It even allows you to jump between the different points in the backtrace, and you'll be able to inspect things right at that point.

Maintenance consequences and Rails 5.0!

As per our maintenance policy, the release of Rails 4.2 will mean that bug fixes will only apply to 4-2-stable, regular security issues to 4.2.x, 4.1.x, and severe security issues to 4.2.x, 4.1.x, and 3.2.x. In addition to these already stated commitments, the honorable Rafael França has agreed to also apply bug fixes to 4-1-stable. So everyone still on 4.1 and unable to move quickly can thank Rafael!

Rails 4.2 will also mark the last big release in the 4.x series. After release, we're going to work towards the big Rails 5.0! This means rails/master will have that target as soon as the release candidates for 4.2 start, and 4-2-stable is created.

Rails 5.0 is in most likelihood going to target Ruby 2.2. There's a bunch of optimizations coming in Ruby 2.2 that are going to be very nice, but most importantly for Rails, symbols are going to be garbage collected. This means we can shed a lot of weight related to juggling strings when we accept input from the outside world. It also means that we can convert fully to keyword arguments and all the other good stuff from the latest Ruby.

The release target for Rails 5.0 is currently spring/summer of 2015. So there's a while yet, but we're putting this out there for people to know, so gem maintainers and other Ruby implementations can know where we're going.

Please help us make Rails 4.2 solid!

We rely on the feedback from everyone in the community to flush out bugs and upgrade issues ahead of a big release like this. So please give Rails 4.2 a try on your app, and if you're starting a new app today, you should probably use the beta1 for that, if you're just the least bit savvy with Rails.

I am happy to announce that Rails 4.1.6.rc1 and 4.0.10.rc1 have been released.

If no regressions are found expect the final release this Friday, on August 22, 2014.
If you find one, please open an issue on GitHub
and mention me (@rafaelfranca) on it, so that we can fix it before the final release.

CHANGES since 4.0.9

To view the changes for each gem, please read the changelogs on GitHub:

These three releases contain important security fixes, so please upgrade as soon
as possible! In order to make upgrading as smooth as possible, we've only
included commits directly related to each security issue.

I am happy to announce that Rails 4.1.2.rc3 and 4.0.6.rc3 have been released.

We fixed two regressions on Active Record component.

If no more new regressions are found expect the final release this Thursday, on Jun 26, 2014.
If you find one, please open an issue on GitHub
and mention me (@rafaelfranca) on it, so that we can fix it before the final release.

CHANGES since 4.0.5

To view the changes for each gem, please read the changelogs on GitHub:

I am happy to announce that Rails 4.1.2.rc2 and 4.0.6.rc2 have been released.

We had a regression with the protected_attributes gem, so if you are using it in your Rails
application make sure you are using protected_attributes 1.0.8 to get it working with these Rails
versions.

If no new regressions are found expect the final release this Thursday, on Jun 19, 2014.
If you find one, please open an issue on GitHub
and mention me (@rafaelfranca) on it, so that we can fix it before the final release.

CHANGES since 4.0.5

To view the changes for each gem, please read the changelogs on GitHub:

I am happy to announce that Rails 4.1.2.rc1 is the first bug fix release for the 4.1 series.
Also, we are releasing a new bug fix release for the 4.0 series, as 4.0.6.rc1.

If no regressions are found expect the final release this Friday, on May 30, 2014.
If you find one, please open an Issue on GitHub and mention me (@rafaelfranca) on it,
so that we can fix it before the final release.

CHANGES since 4.0.5

To view the changes for each gem, please read the changelogs on GitHub:

These three releases contain important security fix, so please upgrade as soon
as possible! In order to make upgrading as smooth as possible, we've only
included commits directly related to each security issue.

Rails 4.1.0 might carry a minor version bump, but there's nothing minor about the bag of goodies it carries. It simply means that upgrading from 4.0.x should be a relatively mild affair as most of the changes are additions or improvements, not backwards-incompatible changes. Let's go over some of those new goodies.

Spring is our new application preloader. It makes running tests, rake, and generators much faster on large applications. You could think of what we had before as the CGI-mode of the command-line. Every time you ran rake, your entire application would be loaded from scratch, only to be thrown out as soon as the command finished. With Spring, your application is a persistent process that can be reused across commands, so only the first run is slow. And we automatically detect code changes, and reload just those parts. It makes a big difference!

Variants allows you to have different templates and action responses for the same mime type (say, HTML). This is a magic bullet for any Rails app that's serving mobile clients. You can now have individual templates for the desktop, tablet, and phone views while sharing all the same controller logic. This is the secret sauce behind Basecamp's hybrid native/HTML strategy for mobile apps: One Rails app serving desktop browsers, mobile browsers, native mobile apps. The reuse benefits are immense and the productivity boost staggering. Really.

Enums wraps the pattern of having a status field constrained to just a few options. It's just enough syntactic sugar to make tinyint-backed status fields taste delicious while still reaping the optimization benefit of avoiding repeated status strings. Poor man's state machine? Nah, Just Enough for Most of the Time.

Mailer previews make it dead simple to visually iterate over your Action Mailer views with test data, so you can get the same work flow as you have for any other view in your app. Make a change, reload to see it. Easy as pie. And certainly a lot better than either starting with static files that then have to be converted to mailer templates, or trying to copy'n'paste the HTML out of the log files to view them in a browser (come on, you've been there!).

Finally, we've committed to moving production passwords out of your application repository with two changes. The first is secrets.yml, which gives you one place and one convenient interface to access secrets that have been set either via ENV variables or deployment scripts. By default it's used for the secret token guarding cookie integrity, but you can use it for whatever else you need in your app. Second is that we've added support for database URLs in database.yml, and that we by default will be referring to ENV-backed URLs in the generated files. Hurray security!

This is intended as the last stop before the final version of Rails 4.1.0 hits the virtual presses. We've been stamping out bugs and polishing things for about a month since the last release candidate. Thanks to everyone who so graciously helped report issues and work on getting things fixed. It makes a big difference to the final product!

Please do the same with this version. If you haven't already given a release candidate a try, this is an excellent time to do so. We expect very little to change between this version and the forthcoming final release. Barring any major upsets, we shouldn't be more than a few weeks out from the final release. Just in time for RailsConf!

We have a 4-1-0 branch that's tracking rc2 through release of final. And we have a 4-1-stable branch that has a few more fixes for things that weren't appropriate to throw into the release candidate cycle. Finally, there's of course rails/master which now targets 4.2.0, so expect a bit more flux there. Oh, and of course the v4.1.0.rc2 tag for this particular release.

I am happy to announce that Rails 4.0.4.rc1 has been released. This is a bug fix release and
includes more than 290 commits.

If no regressions are found we will release 4.0.4 final this Friday, on March 14, 2014.
If you find one, please open an Issue on GitHub and mention me (@rafaelfranca) on it,
so that we can fix it before the final release.

CHANGES since 4.0.3

To view the changes for each gem, please read the changelogs on GitHub:

We're getting really close to signing off on Rails 4.1.0, but we need your help to push it the last mile. Today we're putting out the first (and, with luck, only) release candidate of Rails 4.1.0. It would be swell if you would try it out and tell us where it breaks.

It's already in really good shape (we've been running beta1 and forward in production for Basecamp for months), but still, let's make it a shiny gemstone for release.

These three releases contain important security fixes, so please upgrade as soon
as possible! In order to make upgrading as smooth as possible, we've only
included commits directly related to each security issue.

Hohoho, it's Xmas time, kids! We have a beta full of goodies for everyone who's been nice this year. Rails 4.1 is packed to the gills with more marvelous real-world feature extractions, bug fixes, and the tireless polish only a community full of Rails elves could bestow it with.

While this is just a beta release, it's arguably a lot better tested and ready than most of our previous beta releases. The bulk of what's new are legit bug fixes and additional features. Less shifting of the tectonic plates of the architecture this time around. This should hopefully mean relatively smooth sailing for anyone on 4.0 who wish to upgrade.

In fact, we're already running beta1 in production for Basecamp, so you know it's been taking a good beating. This helped us catch a couple of performance regressions, and we've verified that everything is still spiffy fast on Basecamp.

This new release also follows our new policy of targeting a minor release every six months. The idea being that the jump from minor to minor shouldn't try to include everything under the sun. Just whatever is ready after the six month mark.

So there are already a laundry list of things lined up for 4.2, but that's alright. We can target for that to land in another six months or so.

I am happy to announce that Rails 4.0.1 has been released. This is a bug fix release and
includes more than 460 commits.

This release comes up with an important change on how Active Record handles subsequent order calls.
In Rails 4.0.0 when you do something like this:

User.order("name asc").order("created_at desc")

The latter called order will be prepended in the ORDER BY clause resulting on this SQL:

SELECT*FROMusersORDERBYcreated_atdesc,nameasc

In Rails 4.0.1 the behavior of Rails 3 has been restored and the generated ORDER BY clause
looks like this:

SELECT*FROMusersORDERBYnameasc,created_atdesc

We chose to revert the behavior because it added a major backward incompatibility that made
harder to have an upgrade path without major changes in the application code. Also we consider
the older behavior a bug since it behaves differently from all the others scope methods when they
are chained. So we took the most conservative path of reverting it to be consistent with the idea
of having a smoother upgrade path to Rails 4.

For those who want the old behavior you can use .reorder
or .unscope
to remove the ORDER BY clause and generate another one.

Also, this release adds some performance improvements to make Rails 4 even faster.

CHANGES since 4.0.0

To view the changes for each gem, please read the changelogs on GitHub:

I am happy to announce that Rails 4.0.1.rc1 has been released. This is a bug fix release and
includes more than 450 commits.

This release comes up with an important change on how Active Record handles subsequent order calls.
In Rails 4.0.0 when you do something like this:

User.order("name asc").order("created_at desc")

The later called order will be prepended in the ORDER BY clause resulting on this SQL:

SELECT*FROMusersORDERBYcreated_atdesc,nameasc

In Rails 4.0.1 the behavior of Rails 3 has been restored and the generated ORDER BY clause
looks like this:

SELECT*FROMusersORDERBYnameasc,created_atdesc

We chose to revert the behavior because it added a major backward incompatibility that made
harder to have an upgrade path without major changes in the application code. So we took the most
conservative path of reverting it to be consistent with the idea of having a smoother upgrade path
to Rails 4.

Also, this release adds some performance improvements to make Rails 4 even faster.

If no regressions are found we will release 4.0.1 final this Tuesday, on October 22, 2013.
If you find one, please open an Issue on GitHub and mention me (@rafaelfranca) on it,
so that we can fix it before the final release.

CHANGES since 4.0.0

To view the changes for each gem, please read the changelogs on GitHub:

I am happy to announce that Rails 3.2.14 has been released. This is a bug fix release and
includes more than 150 commits.

I also want to announce that the next 3.2.x release, 3.2.15, will be the last bug fix release
of this family. After it we will only release security fixes. So, if you have issues on 3.2.x
that you think should be included on 3.2.15, let us know thought the
GitHub issues page and in 3 months we'll evaluate if it
is time to release.

CHANGES since 3.2.13

Action Mailer

No changes.

Action Pack

Merge :action from routing scope and assign endpoint if both :controller
and :action are present. The endpoint assignment only occurs if there is
no :to present in the options hash so should only affect routes using the
shorthand syntax (i.e. endpoint is inferred from the the path).

Fix explicit names on multiple file fields. If a file field tag has
the multiple option, it is turned into an array field (appending []),
but if an explicit name is passed to file_field the [] is not
appended.
Fixes #9830.

Ryan McGeary

Fix assets loading performance in 3.2.13.

Issue #8756 uses Sprockets for resolving files that already exist on disk,
for those files their extensions don't need to be rewritten.

Fixes #9803.

Fred Wu

Fix ActionController#action_missing not being called.
Fixes #9799.

Janko Luin

ActionView::Helpers::NumberHelper#number_to_human returns the number unaltered when
the units hash does not contain the needed key, e.g. when the number provided is less
than the largest key provided.

Fix a bug that prevented the use of the default STI inheritance column
(ActiveRecord::Base.inheritance_column = 'some_column'.)

chapmajs + Takehiro Adachi

Fix mysql2 adapter raises the correct exception when executing a query on a
closed connection.

Yves Senn

Fixes bug where Company.new.contract_ids would incorrectly load
all non-associated contracts.

Example:

company = Company.new # Company has many :contracts
# before
company.contract_ids # => SELECT ... WHERE `contracts`.`company_id` IS NULL
# after
company.contract_ids # => []

Jared Armstrong

Fix the :primary_key option for has_many associations.
Fixes #10693.

Yves Senn

fixes bug introduced by #3329. Now, when autosaving associations,
deletions happen before inserts and saves. This prevents a 'duplicate
unique value' database error that would occur if a record being created had
the same value on a unique indexed field as that of a record being destroyed.

Backport of #10417

Johnny Holton

Fix that under some conditions, Active Record could produce invalid SQL of the sort:
"SELECT DISTINCT DISTINCT".

Revert changes on pluck that was ignoring the select clause when the relation already
has one. This caused a regression since it changed the behavior in a stable release.

Fixes #9777.

Rafael Mendonça França

Confirm a record has not already been destroyed before decrementing counter cache.

Ben Tucker

Default values for PostgreSQL bigint types now get parsed and dumped to the
schema correctly.
Backport #10098.

Erik Peterson

Removed warning when auto_explain_threshold_in_seconds is set and the
connection adapter doesn't support explain.
This is causing a regression since the Active Record Railtie is trying to
connect to the development database in the application boot.

Rafael Mendonça França

Do not reset inheritance_column when it's set explicitly.
Backport of #5327.

kennyj + Fred Wu

Fix a problem wrong exception is occured
when raising no translatable exception in PostgreSQL.

kennyj

Resets the postgres search path in the structure.sql after the structure
is dumped in order to find schema_migrations table when multiples schemas
are used.
Fixes #9796.

Juan M. Cuello + Dembskiy Alexander

Reload the association target if it's stale. @stale_state should be nil
when a model isn't saved.
Fixes #7526.

Larry Lv

Don't read CSV files during execution of db:fixtures:load. CSV support for
fixtures was removed some time ago but the task was still loading them, even
though later the code was looking for the related yaml file instead.

kennyj

Active Resource

Fixes an issue that ActiveResource models ignores ActiveResource::Base.include_root_in_json.
Backported from the now separate repo rails/activeresouce.

Xinjiang Lu

Active Support

Make Time.at_with_coercion retain the second fraction and return local time.

Fixes #11350

Neer Friedman, Andrew White

Fix ActiveSupport::TaggedLogging incorrectly providing program name the same as log message
even when block is not provided.

Carson Reinke

Override Time.at to support the passing of Time-like values when called with a single argument.

Andrew White

Revert the changes on unicode character encoding from ActiveSupport::JSON.encode.
This was causing a regression where the resulting string is always returning UTF-8.
Also it changes the behavior of this method on a stable release.
Fixes #9498.

Rafael Mendonça França

Fix ActiveSupport::TimeZone.parse when time is at a local DST jump.
Fixes #9678.

One regression was found on the 3.2.14.rc1 release. So, following the script
We are releasing a new release candidate, Rails 3.2.14.rc2.

If no regressions are found we will release 3.2.14 final final this Friday, on July
19, 2013. If you find one, please open an Issue on
GitHub and mention me (@rafaelfranca) on it,
so that we can fix it before the final release.

I am happy to announce that Rails 3.2.14.rc1 has been released. If no regressions
are found I will release 3.2.14 final final this Monday, on July
15, 2013. If you find one, please open an Issue on
GitHub and mention me on it,
so that I can fix it before the final release.

CHANGES since 3.2.13

Action Mailer

No changes.

Action Pack

Merge :action from routing scope and assign endpoint if both :controller
and :action are present. The endpoint assignment only occurs if there is
no :to present in the options hash so should only affect routes using the
shorthand syntax (i.e. endpoint is inferred from the the path).

Fix explicit names on multiple file fields. If a file field tag has
the multiple option, it is turned into an array field (appending []),
but if an explicit name is passed to file_field the [] is not
appended.
Fixes #9830.

Ryan McGeary

Fix assets loading performance in 3.2.13.

Issue #8756 uses Sprockets for resolving files that already exist on disk,
for those files their extensions don't need to be rewritten.

Fixes #9803.

Fred Wu

Fix ActionController#action_missing not being called.
Fixes #9799.

Janko Luin

ActionView::Helpers::NumberHelper#number_to_human returns the number unaltered when
the units hash does not contain the needed key, e.g. when the number provided is less
than the largest key provided.

Fix a bug that prevented the use of the default STI inheritance column
(ActiveRecord::Base.inheritance_column = 'some_column'.)

chapmajs + Takehiro Adachi

Fix mysql2 adapter raises the correct exception when executing a query on a
closed connection.

Yves Senn

Fixes bug where Company.new.contract_ids would incorrectly load
all non-associated contracts.

Example:

company = Company.new # Company has many :contracts
# before
company.contract_ids # => SELECT ... WHERE `contracts`.`company_id` IS NULL
# after
company.contract_ids # => []

Jared Armstrong

Fix the :primary_key option for has_many associations.
Fixes #10693.

Yves Senn

fixes bug introduced by #3329. Now, when autosaving associations,
deletions happen before inserts and saves. This prevents a 'duplicate
unique value' database error that would occur if a record being created had
the same value on a unique indexed field as that of a record being destroyed.

Backport of #10417

Johnny Holton

Fix that under some conditions, Active Record could produce invalid SQL of the sort:
"SELECT DISTINCT DISTINCT".

Revert changes on pluck that was ignoring the select clause when the relation already
has one. This caused a regression since it changed the behavior in a stable release.

Fixes #9777.

Rafael Mendonça França

Confirm a record has not already been destroyed before decrementing counter cache.

Ben Tucker

Default values for PostgreSQL bigint types now get parsed and dumped to the
schema correctly.
Backport #10098.

Erik Peterson

Removed warning when auto_explain_threshold_in_seconds is set and the
connection adapter doesn't support explain.
This is causing a regression since the Active Record Railtie is trying to
connect to the development database in the application boot.

Rafael Mendonça França

Do not reset inheritance_column when it's set explicitly.
Backport of #5327.

kennyj + Fred Wu

Fix a problem wrong exception is occured
when raising no translatable exception in PostgreSQL.

kennyj

Resets the postgres search path in the structure.sql after the structure
is dumped in order to find schema_migrations table when multiples schemas
are used.
Fixes #9796.

Juan M. Cuello + Dembskiy Alexander

Reload the association target if it's stale. @stale_state should be nil
when a model isn't saved.
Fixes #7526.

Larry Lv

Don't read CSV files during execution of db:fixtures:load. CSV support for
fixtures was removed some time ago but the task was still loading them, even
though later the code was looking for the related yaml file instead.

kennyj

Active Resource

Fixes an issue that ActiveResource models ignores ActiveResource::Base.include_root_in_json.
Backported from the now separate repo rails/activeresouce.

Xinjiang Lu

Active Support

Make Time.at_with_coercion retain the second fraction and return local time.

Fixes #11350

Neer Friedman, Andrew White

Fix ActiveSupport::TaggedLogging incorrectly providing program name the same as log message
even when block is not provided.

Carson Reinke

Override Time.at to support the passing of Time-like values when called with a single argument.

Andrew White

Revert the changes on unicode character encoding from ActiveSupport::JSON.encode.
This was causing a regression where the resulting string is always returning UTF-8.
Also it changes the behavior of this method on a stable release.
Fixes #9498.

Rafael Mendonça França

Fix ActiveSupport::TimeZone.parse when time is at a local DST jump.
Fixes #9678.

Rails 4.0 is finally ready after a thorough process of betas and release candidates. It's an amazing new version packed with new goodies and farewells to old features past their expiration date.

A big focus has been on making it dead simple to build modern web applications that are screaming fast without needing to go the client-side JS/JSON server route. Much of this work was pioneered for Rails in the new version of Basecamp and focuses on three aspects:

Make it super easy to do Russian Doll-caching through key-based expiration with automatic dependency management of nested templates (explored first in the cache_digests plugin).

Speed-up the client-side with Turbolinks, which essentially turns your app into a single-page javascript application in terms of speed, but with none of the developmental drawbacks (except, maybe, compatibility issues with some existing JavaScript packages).

Rails is of course still a great JSON server for people who want to build client-side JS views with Ember.js, Backbone.js or Angular.js, but with the progress we've made for Rails 4.0, you certainly won't need to go down that route just to have a super fast application.

Active Record has received a ton of love as well to make everything related to scoping and the query structure more consistent. We've also locked down the general security defaults even tighter with this version.

On top of these new features and fixes, we have hundreds more of all sorts. Everything has been combed over, streamlined, simplified, and we've extracted out lots of old APIs and things that just don't fit "most people most of the time".

If you're upgrading an existing application to Rails 4, have a look at the upgrade guide or the Railscast screencast. As always, install the latest with gem install rails --version 4.0.0 --no-ri --no-rdoc or depend on the v4.0.0 tag. If you haven't already, now is a good time to upgrade to Ruby 2.0 as well. Rails 5+ will require Ruby 2.0, so you might as well get a head start.

Finally, thanks to everyone who contributed to this release. There has been some 10,000 commits between the latest 3.2 release and Rails 4.0 and ~500 people have contributed in 2013 alone. We have a bigger and more engaged community than ever before and it shows: Rails 4 is an incredibly polished release. It's a real milestone and something for everyone in the community to be proud of.

We're almost at the end of the road for Rails 4.0.0. This is intended to be the last release candidate before the final version is released. We have just under a hundred commits in since RC1. All just fixing regressions since the last release.

As last time, please give this release candidate an honest try. This is the version we're going to ship on June 25th unless people find and report blocking issues. Please report all the issues you find on the Rails issue tracker.

As always, install the release with gem install rails --version 4.0.0.rc2 --no-ri --no-rdoc or depend on the v4.0.0.rc2 tag. You can also follow the 4-0-0 branch. 4-0-0-stable is now targeting 4.0.1 and master is targeting 4.1.

As last time, please give this release candidate an honest try. This is pretty much the version we're going to ship unless people find and report blocking issues. Depending on how much stuff is unearthed, we expect that the final version could drop in as little as 3-4 weeks. Please report all the issues you find on the Rails issue tracker.

As always, install the release with gem install rails --version 4.0.0.rc1 --no-ri --no-rdoc or depend on the v4.0.0.rc1 tag. We also have a new 4-0-stable branch. Master is now safe to move on to developing features for 4.1.

All versions of Rails are impacted by one or more of these security issues, but per our maintenance policy, only versions 3.2.13, 3.1.12, and 2.3.18 have been released. You can find patches for older versions on each stable branch on GitHub:

Hey everyone! I am pumped to announce that Rails 3.2.13.rc1 has been released!
If no regressions are found I will release 3.2.13 final in two weeks, on March
13, 2013. If you find one, please Open an Issue on
GitHub so that I can fix it before
the final release.

This is a bugfix release, with 287 commits. There is one big thing that is
technically a fix but is sort of a feature: Ruby 2.0 support. Big thanks to
Prem Sichanugrist for putting that together! Please give your applications a
try on Ruby 2.0 and let me know how that goes.

CHANGES since 3.2.12

Action Mailer

No changes.

Action Pack

Determine the controller#action from only the matched path when using the
shorthand syntax. Previously the complete path was used, which led
to problems with nesting (scopes and namespaces).
Fixes #7554.
Backport #9361.

Example:

# this will route to questions#new
scope ':locale' do
get 'questions/new'
end

Introduce ActionView::Template::Handlers::ERB.escape_whitelist. This is a list
of mime types where template text is not html escaped by default. It prevents Jack & Joe
from rendering as Jack &amp; Joe for the whitelisted mime types. The default whitelist
contains text/plain. Fix #7976 [Backport #8235]

Previously, when time_zone_aware_attributes were enabled, after
changing a datetime or timestamp attribute and then changing it back
to the original value, changed_attributes still tracked the
attribute as changed. This caused [attribute]_changed? and
changed? methods to return true incorrectly.

Add ActiveRecord::Base.cache_timestamp_format class attribute to control
the format of the timestamp value in the cache key.
This allows users to improve the precision of the cache key.
Fixes #8195.

Rafael Mendonça França

Add :nsec date format. This can be used to improve the precision of cache key.
Please note that this format only works with Ruby 1.9, Ruby 1.8 will ignore it completely.

Jamie Gaskins

Unscope update_column(s) query to ignore default scope.

When applying default_scope to a class with a where clause, using
update_column(s) could generate a query that would not properly update
the record due to the where clause from the default_scope being applied
to the update query.

In this situation we want to skip the default_scope clause and just
update the record based on the primary key. With this change:

user.update_column(:active, true) # => true

Backport of #8436 fix.

Carlos Antonio da Silva

Fix performance problem with primary_key method in PostgreSQL adapter when having many schemas.
Uses pg_constraint table instead of pg_depend table which has many records in general.
Fix #8414

kennyj

Do not instantiate intermediate Active Record objects when eager loading.
These records caused after_find to run more than expected.
Fix #3313
Backport of #8403

Yves Senn

Fix pluck to work with joins. Backport of #4942.

Carlos Antonio da Silva

Fix a problem with translate_exception method in a non English environment.
Backport of #6397.

kennyj

Fix dirty attribute checks for TimeZoneConversion with nil and blank
datetime attributes. Setting a nil datetime to a blank string should not
result in a change being flagged.
Fixes #8310.
Backport of #8311.

Alisdair McDiarmid

Prevent mass assignment to the type column of polymorphic associations when using build.
Fixes #8265.
Backport of #8291.

Yves Senn

When running migrations on Postgresql, the :limit option for binary and text columns is
silently dropped.
Previously, these migrations caused sql exceptions, because Postgresql doesn't support limits
on these types.

Victor Costan

#pluck can be used on a relation with select clause.
Fixes #7551.
Backport of #8176.

Example:

Topic.select([:approved, :id]).order(:id).pluck(:id)

Yves Senn

Use nil? instead of blank? to check whether dynamic finder with a bang
should raise RecordNotFound.
Fixes #7238.

Nikita Afanasenko

Fix deleting from a HABTM join table upon destroying an object of a model
with optimistic locking enabled.
Fixes #5332.

Nick Rogers

Use query cache/uncache when using ENV["DATABASE_URL"].
Fixes #6951.
Backport of #8074.

kennyj

Do not create useless database transaction when building has_one association.

Remove surrogate unicode character encoding from ActiveSupport::JSON.encode
The encoding scheme was broken for unicode characters outside the basic
multilingual plane; since json is assumed to be UTF-8, and we already force the
encoding to UTF-8 simply pass through the un-encoded characters.

Hot on the heels of the first production version of Ruby 2.0 comes the first beta version of Rails 4.0. The two form a great pair and are already running in production on a number of applications, including Basecamp Breeze. In fact, Ruby 2.0 is the preferred Ruby to use with Rails 4.0.

The purpose of this beta is to get as many people as possible to try to upgrade from Rails 3.2 and earlier and to get an adventurous few to start new applications directly on Rails 4.0. That's the only way we're going to suss out all the issues and ensure that we can launch a solid final release. So please help us with that if you can!

Rails 4.0 is packed with new goodies and farewells to old goodies past their expiration date.

A big focus has been on making it dead simple to build modern web applications that are screaming fast without needing to go the client-side JS/JSON server route. Much of this work was pioneered for Rails in the new version of Basecamp and focuses on three aspects:

Make it super easy to do Russian Doll-caching through key-based expiration with automatic dependency management of nested templates (explored first in the cache_digests plugin).

Speed-up the client-side with Turbolinks, which essentially turns your app into a single-page javascript application in terms of speed, but with none of the developmental drawbacks (except, maybe, compatibility issues with some existing JavaScript packages).

Rails is of course still a great JSON server for people who want to build client-side JS views, but with the progress we've made for Rails 4.0, you certainly won't need to go down that route just to have a super fast application.

On top of these new features and fixes, we have hundreds more of all sorts. Everything has been combed over, streamlined, simplified, and we've extracted out lots of old APIs and things that just don't fit "most people most of the time".

Now let's all work together to ensure the release is final and enjoy the bad-ass combination of Ruby on Rails 24! (Or 42?). Please report all the issues you find on the Rails issue tracker. We're still working on the upgrade guide from 3.2 to 4.0, but that's a good place to start for help on how to do it. As always, install betas with gem install rails --version 4.0.0.beta1 --no-ri --no-rdoc (--pre and ri generation is busted on RubyGems 2.0 at the moment) or depend on the v4.0.0.beta1 tag.

Since the most recent patch releases there has been some confusion about what
versions of Ruby on Rails are currently supported, and when people can expect
new versions. Our maintenance policy is as follows.

Support of the Rails framework is divided into four groups: New features, bug
fixes, security issues, and severe security issues. They are handled as
follows, all versions in x.y.z format:

New Features

New Features are only added to the master branch and will not be made available
in point releases.

Bug fixes

Only the latest release series will receive bug fixes. When enough bugs are
fixed and its deemed worthy to release a new gem, this is the branch it happens
from.

Currently included series: 3.2.z

After the Rails 4 release: 4.0.z

Security issues:

The current release series and the next most recent one will receive patches
and new versions in case of a security issue.

These releases are created by taking the last released version, applying the
security patches, and releasing. Those patches are then applied to the end of
the x-y-stable branch. For example, a theoretical 1.2.3 security release would
be built from 1.2.2, and then added to the end of 1-2-stable. This means that
security releases are easy to upgrade to if you're running the latest version
of Rails.

Currently included series: 3.2.z, 3.1.z

After the Rails 4 release: 4.0.z, 3.2.z

Severe security issues:

For severe security issues we will provide new versions as above, and also the
last major release series will receive patches and new versions. The
classification of the security issue is judged by the core team.

Currently included series: 3.2.z, 3.1.z, 2.3.z

After the Rails 4 release: 4.0.z, 3.2.z

Unsupported Release Series

When a release series is no longer supported, it's your own responsibility to
deal with bugs and security issues. We may provide back-ports of the fixes and
publish them to git, however there will be no new versions released. If you
are not comfortable maintaining your own versions, you should upgrade to a
supported version.

You should also be aware that Ruby 1.8 will reach End of Life in June 2013, no
further Ruby security releases will be provided after that point. If your
application is only compatible Ruby 1.8 you should upgrade accordingly.

Please note that today a new JSON gem was released, and it also contains an important security fix. You should update the JSON gem as soon as possible. You can read about the security issue in the JSON gem here:

Rails 3.2.8.rc1 has been released. If no regressions are found we will
release 3.2.8 final on Friday.

IMPORTANT

We are removing all the deprecation warnings that we introduced in 3.2.x.
We have decided to stop introducing API deprecations in all point releases going forward. From now on, it'll only happen in majors/minors.

So we didn’t quite make the December release date as we intended, but hey, why break a good tradition and start hitting release targets now! In any case, your patience has been worldly rewarded young grasshopper: Rails 3.2 is done, baked, tested, and ready to roll!

I’ve been running on 3-2-stable for a few months working on Basecamp Next and it’s been a real treat. The new faster dev mode in particular is a major step up over 3.1.

Do remember that this is the last intended release series that’s going to support Ruby 1.8.7. The master git branch for Rails is now targeting Rails 4.0, which will require Ruby 1.9.3 and above. So now is a great time to start the work on getting your app ready for the current version of Ruby. Let’s not hang around old versions forever and a Sunday like those Python guys :).

Note: If you’re having trouble installing the gems under Ruby 1.8.7, you’ve probably hit a RubyGems bug with YAML that’s been fixed in RubyGems 1.8.15. You can upgrade RubyGems using “gem update —system”.

If you can’t be bothered with the full release notes, here’s a reprint of a few feature highlights from when we did the first release candidate:

Faster dev mode & routing

The most noticeable new feature is that development mode got a ton and a half faster. Inspired by Active Reload, we now only reload classes from files you’ve actually changed. The difference is dramatic on a larger application.

Route recognition also got a bunch faster thanks to the new Journey engine and we made linking much faster as well (especially apparent when you’re having 100+ links on a single page).

Explain queries

We’ve added a quick and easy way to explain quieries generated by ARel. In the console, you can run something like puts Person.active.limit(5).explain and you’ll get the query ARel produces explained (so you can easily see whether its using the right indexes). There’s even a default threshold in development mode where if a query takes more than half a second to run, it’s automatically explained inline — how about that!

Tagged logger

When you’re running a multi-user, multi-account application, it’s a great help to be able to filter the log by who did what. Enter the TaggedLogging wrapper. It works like this:

What to update in your apps

Extract your vendor/plugins to their own gems and bundle them in your Gemfile. If they're tiny, not worthy of the own gem, fold it into your app as lib/myplugin/* and config/initializers/myplugin.rb.

Changes since RC1

Action Mailer

No changes

Action Pack

Add font_path helper method Santiago Pastorino

Depends on rack ~> 1.4.0 Santiago Pastorino

Add :gzip option to caches_page. The default option can be configured globally using page_cache_compressionAndrey Sitnik

Active Model

No changes

Active Record

No changes

Active Resource

No changes

Active Support

ActiveSupport::Base64 is deprecated in favor of ::Base64. Sergey Nartimov

Railties

Rails 2.3-style plugins in vendor/plugins are deprecated and will be removed in Rails 4.0. Move them out of vendor/plugins and bundle them in your Gemfile, or fold them in to your app as lib/myplugin/* and config/initializers/myplugin.rb. Santiago Pastorino

Guides are available as a single .mobi for the Kindle and free Kindle readers apps. Michael Pearson & Xavier Noria

Allow scaffold/model/migration generators to accept a "index" and "uniq" modifiers, as in: "tracking_id:integer:uniq" in order to generate (unique) indexes. Some types also accept custom options, for instance, you can specify the precision and scale for decimals as "price:decimal{7,2}". Dmitrii Samoilov

Once you’ve boarded the Rails train, you just know that every stop along the way is going to be a good time. This release candidate is no different and we’ve packed it with loving goodies without making upgrading a hassle.

Faster dev mode & routing

The most noticeable new feature is that development mode got a ton and a half faster. Inspired by Active Reload, we now only reload classes from files you’ve actually changed. The difference is dramatic on a larger application.

Route recognition also got a bunch faster thanks to the new Journey engine and we made linking much faster as well (especially apparent when you’re having 100+ links on a single page).

Explain queries

We’ve added a quick and easy way to explain quieries generated by ARel. In the console, you can run something like puts Person.active.limit(5).explain and you’ll get the query ARel produces explained (so you can easily see whether its using the right indexes). There’s even a default threshold in development mode where if a query takes more than half a second to run, it’s automatically explained inline — how about that!

Tagged logger

When you’re running a multi-user, multi-account application, it’s a great help to be able to filter the log by who did what. Enter the TaggedLogging wrapper. It works like this:

Unfortunately I accidentally pushed an incorrect v3.1.2 tag yesterday. I immediately recognised that it was wrong, so quickly deleted it and pushed the correct tag. I thought that this would not be a problem for anyone who was not pulling the rails repository at that exact moment.

It turns out I was wrong. If you have a rails repository clone that existed before the 3.1.2 release, in order to get the v3.1.2 tag into your repository, you will need to do:

Changing rake db:schema:dump to run :environment as well as :load_config,
as running :load_config alone will lead to the dumper being run without
including extensions such as those included in foreigner and
spatial_adapter.

This reverses a change made here:
https://github.com/rails/rails/commit/5df72a238e9fcb18daf6ab6e6dc9051c9106d7bb#L0L324

I'm assuming here that :load_config needs to be invoked
separately from :environment, as it is elsewhere in the
file for db operations, if not the alternative is to go
back to "task :dump => :environment do".

[Ben Woosley]

Update to rack-cache 1.1.

Versions prior to 1.1 delete the If-Modified-Since and If-Not-Modified
headers when config.action_controller.perform_caching is true. This has two
problems:
* unexpected inconsistent behaviour between development &
production environments
* breaks applications that use of these headers

[Brendan Ribera]

Ensure that enhancements to assets:precompile task are only run once [Sam Pohlenz]

TestCase should respect the view_assigns API instead of pulling variables on
its own. [José Valim]

javascript_path and stylesheet_path now refer to /assets if asset pipelining
is on. [Santiago Pastorino]

button_to support form option. Now you're able to pass for example
'data-type' => 'json'. [ihower]

image_path and image_tag should use /assets if asset pipelining is turned
on. Closes #3126 [Santiago Pastorino and christos]

Allow asset tag helper methods to accept :digest => false option in order to completely avoid the digest generation.
Useful for linking assets from static html files or from emails when the user
could probably look at an older html email with an older asset. [Santiago Pastorino]

Fixed the behavior of asset pipeline when config.assets.digest and config.assets.compile are false and requested asset isn't precompiled.
Before the requested asset were compiled anyway ignoring that the config.assets.compile flag is false. [Guillermo Iguaran]

Database adapters use a statement pool for limiting the number of open
prepared statments on the database. The limit defaults to 1000, but can
be adjusted in your database config by changing 'statement_limit'.

Fix clash between using 'preload', 'joins' or 'eager_load' in a default scope and including the
default scoped model in a nested through association. (GH #2834.) [Jon Leighton]

Ensure we are not comparing a string with a symbol in HasManyAssociation#inverse_updates_counter_cache?.
Fixes GH #2755, where a counter cache could be decremented twice as far as it was supposed to be.

[Jon Leighton]

Don't send any queries to the database when the foreign key of a belongs_to is nil. Fixes
GH #2828. [Georg Friedrich]

Fixed find_in_batches method to not include order from default_scope. See GH #2832 [Arun Agrawal]

Don't compute table name for abstract classes. Fixes problem with setting the primary key
in an abstract class. See GH #2791. [Akira Matsuda]

Rails 3.1.1.rc3 has been released. Please give it a try, it's our chance to fix regressions you might find and make a beautiful 3.1.1 stable release. If there are no regressions I will be releasing 3.1.1 final next October 7th. If you find any regression please contact me ASAP by email, twitter or github.

Changing rake db:schema:dump to run :environment as well as :load_config,
as running :load_config alone will lead to the dumper being run without
including extensions such as those included in foreigner and
spatial_adapter.

This reverses a change made here:
https://github.com/rails/rails/commit/5df72a238e9fcb18daf6ab6e6dc9051c9106d7bb#L0L324

I'm assuming here that :load_config needs to be invoked
separately from :environment, as it is elsewhere in the
file for db operations, if not the alternative is to go
back to "task :dump => :environment do".

[Ben Woosley]

Update to rack-cache 1.1.

Versions prior to 1.1 delete the If-Modified-Since and If-Not-Modified
headers when config.action_controller.perform_caching is true. This has two
problems:
* unexpected inconsistent behaviour between development &
production environments
* breaks applications that use of these headers

[Brendan Ribera]

Ensure that enhancements to assets:precompile task are only run once [Sam Pohlenz]

TestCase should respect the view_assigns API instead of pulling variables on
its own. [José Valim]

javascript_path and stylesheet_path now refer to /assets if asset pipelining
is on. [Santiago Pastorino]

button_to support form option. Now you're able to pass for example
'data-type' => 'json'. [ihower]

image_path and image_tag should use /assets if asset pipelining is turned
on. Closes #3126 [Santiago Pastorino and christos]

Allow asset tag helper methods to accept :digest => false option in order to completely avoid the digest generation.
Useful for linking assets from static html files or from emails when the user
could probably look at an older html email with an older asset. [Santiago Pastorino]

Fixed the behavior of asset pipeline when config.assets.digest and config.assets.compile are false and requested asset isn't precompiled.
Before the requested asset were compiled anyway ignoring that the config.assets.compile flag is false. [Guillermo Iguaran]

Database adapters use a statement pool for limiting the number of open
prepared statments on the database. The limit defaults to 1000, but can
be adjusted in your database config by changing 'statement_limit'.

Fix clash between using 'preload', 'joins' or 'eager_load' in a default scope and including the
default scoped model in a nested through association. (GH #2834.) [Jon Leighton]

Ensure we are not comparing a string with a symbol in HasManyAssociation#inverse_updates_counter_cache?.
Fixes GH #2755, where a counter cache could be decremented twice as far as it was supposed to be.

[Jon Leighton]

Don't send any queries to the database when the foreign key of a belongs_to is nil. Fixes
GH #2828. [Georg Friedrich]

Fixed find_in_batches method to not include order from default_scope. See GH #2832 [Arun Agrawal]

Don't compute table name for abstract classes. Fixes problem with setting the primary key
in an abstract class. See GH #2791. [Akira Matsuda]

Rails 3.1.1.rc2 has been released. Please give it a try, it's our chance to fix regressions you might find and make a beautiful 3.1.1 stable release. If there are no regressions I will be releasing 3.1.1 final next October 3rd. If you find any regression please contact me ASAP by email, twitter or github.

CHANGES

Action Mailer

No changes

Action Pack

Allow asset tag helper methods to accept :digest => false option in order to completely avoid the digest generation.
Useful for linking assets from static html files or from emails when the user
could probably look at an older html email with an older asset. [Santiago Pastorino]

Fixed the behavior of asset pipeline when config.assets.digest and config.assets.compile are false and requested asset isn't precompiled.
Before the requested asset were compiled anyway ignoring that the config.assets.compile flag is false. [Guillermo Iguaran]

Database adapters use a statement pool for limiting the number of open
prepared statments on the database. The limit defaults to 1000, but can
be adjusted in your database config by changing 'statement_limit'.

Fix clash between using 'preload', 'joins' or 'eager_load' in a default scope and including the
default scoped model in a nested through association. (GH #2834.) [Jon Leighton]

Ensure we are not comparing a string with a symbol in HasManyAssociation#inverse_updates_counter_cache?.
Fixes GH #2755, where a counter cache could be decremented twice as far as it was supposed to be.

[Jon Leighton]

Don't send any queries to the database when the foreign key of a belongs_to is nil. Fixes
GH #2828. [Georg Friedrich]

Fixed find_in_batches method to not include order from default_scope. See GH #2832 [Arun Agrawal]

Don't compute table name for abstract classes. Fixes problem with setting the primary key
in an abstract class. See GH #2791. [Akira Matsuda]

Rails 3.1.1.rc1 has been released. Please give it a try, it's our chance to fix regressions you might find and make a beautiful 3.1.1 stable release. If there are no regressions I will be releasing 3.1.1 final next September 16th during GoGaRuCo.

CHANGES

Action Mailer

No changes

Action Pack

Allow asset tag helper methods to accept :digest => false option in order to completely avoid the digest generation.
Useful for linking assets from static html files or from emails when the user
could probably look at an older html email with an older asset. [Santiago Pastorino]

Fixed the behavior of asset pipeline when config.assets.digest and config.assets.compile are false and requested asset isn't precompiled.
Before the requested asset were compiled anyway ignoring that the config.assets.compile flag is false. [Guillermo Iguaran]

Database adapters use a statement pool for limiting the number of open
prepared statments on the database. The limit defaults to 1000, but can
be adjusted in your database config by changing 'statement_limit'.

Fix clash between using 'preload', 'joins' or 'eager_load' in a default scope and including the
default scoped model in a nested through association. (GH #2834.) [Jon Leighton]

Ensure we are not comparing a string with a symbol in HasManyAssociation#inverse_updates_counter_cache?.
Fixes GH #2755, where a counter cache could be decremented twice as far as it was supposed to be.

[Jon Leighton]

Don't send any queries to the database when the foreign key of a belongs_to is nil. Fixes
GH #2828. [Georg Friedrich]

Fixed find_in_batches method to not include order from default_scope. See GH #2832 [Arun Agrawal]

Don't compute table name for abstract classes. Fixes problem with setting the primary key
in an abstract class. See GH #2791. [Akira Matsuda]

Rails 3.1.0.rc8 has been released (we've an issue with rc7). This is
the final release candidate. Please give it a try, it's our last
chance to fix regressions and severe issues. We will be releasing
final 3.1.0 next August 30th.

As I promised at RailsConf, we’re finally good to go on the Rails 3.1: Release Candidate. This is a fantastically exciting release. We have three new star features and an even greater number of just awesome improvements. First the stars:

The Asset Pipeline
The star feature of 3.1 is the asset pipeline powered by Sprockets 2.0. It makes CSS and JavaScript first-class code citizens and enables proper organization, including use in plugins and engines. See my RailsConf keynote for a full tour. This comes with SCSS as the default for stylesheets and CoffeeScript as the default for JavaScript. Much documentation is on the way for this.

HTTP Streaming
This lets the browser download your stylesheet and javascripts while the server is still generating the response. The result is noticeable faster pages. It’s opt-in and does require support from the web server as well, but the popular combo of nginx and unicorn is ready to take advantage of it. There’s a great Railscast on HTTP streaming and the API documentation is strong too.

jQuery is now the default
We’ve made jQuery the default JavaScript framework that ships with Rails, but it’s silly easy to switch back to Prototype if you fancy. It’s all bundled up in the jquery-rails and prototype-rails gems. Just depend on the one you’d like in the Gemfile and it’ll Just Work.

Identity Map: It’s not enabled by default because of some important caveats that are still to be ironed out, but if you can deal with those, it’s a great way to cut down on the number of queries your app will trigger. Faster is better!

Prepared statements: Active Record now uses cached prepared statements, which is a big boost for PostgreSQL in all cases and a boost for MySQL on complex statements.

If you’re starting a new application, it’s strongly recommended that you do so using Ruby 1.9.2. Rails will continue to support 1.8.x until Rails 4.0, but it’s considered the legacy option. Ruby 1.9.x is where the action is. Get on board and enjoy the massive speed boost.

We’ve taken our first release step towards the final version of Rails 3.1 today with the unveiling of beta 1. This is a release mostly for people who’ve already been following along with the development of Rails 3.1 and want to try a version that’s close to feature complete.

We do not yet have all the documentation ready, so it’s still a bit of a detective job to figure out how it all fits together. Thus, this is not a general release and I wont hold it against you if you’re holding out for a release candidate (coming in the next few weeks).

The tag is 3.1.0.beta1 and you can install using gem install rails --pre. Enjoy!

How about some free speed? Well, here you go. Rails 3.0.3 includes a much faster version of Active Record that reclaims the performance lost when we went from Rails 2.3.x to 3.x and then some. Aaron Patterson has done a phenomenal job benchmarking, tweaking, and tuning the ARel engine that underpins Active Record 3 and the result is Teh Snappy.

You can read more about Aaron’s work in his ARel 2.0 write-up. If you dare, you can also have a look at his RubyConf slides that went over the rewrite and speed-up in even greater detail (warning: there are slides of boys kissing!).

In addition to the free speed, we’ve also included a truckload of minor fixes. So everything just works better and faster. What more can you ask for? Oh, that it’s a drop-in replacement for Rails 3.0 — there are no API changes. You got it.

Note: Active Record 3.0.3 is mistakenly reporting its tiny version as 1 instead of 3. This has no impact on anything you do unless you were specifically checking that tiny version. But if it bothers you lots, it’s fixed on the 3-0-stable branch.

We’ve released Ruby on Rails 2.3.9 (gem and git tag) to extend the 2.3.8 bridge a few steps closer to Rails 3 and Ruby 1.9. If your app runs on Rails 2.3.9 without deprecation warnings, you’re looking good for an upgrade to Rails 3.

Deprecations

Changes i18n named-interpolation syntax from the deprecated Hello to the 1.9-native Hello %{name}.

Replaces Kernel#returning with Object#tap which is native to Ruby 1.8.7.

Renames Array#random_element to Array#sample which is native to Ruby 1.9.

Renames config.load_paths and .load_once_paths to the more accurate config.autoload_paths and .autoload_once_paths.

Along with these deprecations come a broad array of bugfixes and minor tweaks. Read the commit log for the full story.

Rails 3.0 has been underway for a good two years, so it’s with immense pleasure that we can declare it’s finally here. We’ve brought the work of more than 1,600 contributors together to make everything better, faster, cleaner, and more beautiful.

This third generation of Rails has seen thousands of commits, so picking what to highlight was always going to be tough and incomplete. But here’s a choice selection of major changes for Rails 3:

New Active Record query engine
Active Record has adopted the ARel query engine to make scopes and queries more consistent and composable. This makes it much easier to build complex queries over several iterations. We also delay the actual execution of the query until it’s needed. Here’s a simple example:

New router for Action Controller
When we switched to a REST-based approach for controllers in Rails 2, we patched on the syntax to the existing router while we were waiting to see if the experiment panned out.

It did and for Rails 3 we’ve gone back and revamped the syntax completely to favor the REST style with less noise and more flexibility:

New Action Mailer
Action Mailer was born with a split-personality of half model, half controller. In Rails 3, we’ve made the choice to make it all controller. This means that the feel and functionality will be much closer to Action Controller and in fact they now share a bunch of underlying code. Here’s a taste of what it looks like now:

Manage dependencies with Bundler
Managing all the dependencies of a Rails application has long been a hassle of patchworks. We had config.gem, Capistrano externals, custom rake setup tasks, and other incomplete solutions.

Bundler cleans all that up and allows you to specify the libraries, frameworks, and plugins that your application depends on. All Rails 3 applications are born with a Gemfile to control it all. See more on the Bundler site.

XSS protection by default
The internet is a scary place and Rails 3 is watching out for you by default. We’ve had CRSF protection with form signing for a while and SQL-injection protection since the beginning, but Rails 3 ups the anté with XSS protection as well (hat tip to Django for convincing us).

Say goodbye to encoding issues
If you browse the Internet with any frequency, you will likely encounter the &#xFFFD; character. This problem is extremely pervasive, and is caused by mixing and matching content with different encodings.

In a system like Rails, content comes from the database, your templates, your source files, and from the user. Ruby 1.9 gives us the raw tools to eliminate these problems, and in combination with Rails 3, &#xFFFD; should be a thing of the past in Rails applications. Never struggle with corrupted data pasted by a user from Microsoft Word again!

Active Model: Validations, callbacks, etc for all models
We’ve extracted quite a bit of commonly requested Active Record components into the new Active Model framework. This allows an ORM like Mongoid to use Active Record’s validations, callbacks, serialization, and i18n support.

Additionally, in the rewrite of Action Controller, we removed any direct references to Active Record, defining a clean, simple API that ORMs can implement. If you use an API-compliant ORM (like DataMapper, Sequel, or Mongoid), you will be able to use features like form_for, link_to and redirect_to with objects from those ORMs without any additional work.

Official plugin APIs
We also rewrote Railties with the express goal of using the new plugin API for all Rails frameworks like Active Record and Action Mailer. This means that Rails plugins like the ones for DataMapper and RSpec have access to all of the integration as the built-in support for Active Record and Test::Unit.

The new Railtie API makes it possible to modify the built-in generators, add rake tasks, configure default Rails options, and specify code to run as early, or as late as you need. Rails plugins like Devise were able to add much better integration in the Rails 3 version of their plugin. Expect to see a lot more of that in the months ahead.

Rewritten internals
We rewrote the internals of Action Pack and Railties, making them much more flexible and easier to extend. Instead of a single monolithic ActionController::Base, Rails 3 exposes a number of modules, each with defined APIs, that you can mix and match to create special-purpose controllers for your own use. Both Action Mailer in Rails and the Cells project make heavy use of this new functionality.

You can also take a look a this blog post by Yehuda (from last year) to see how the new architecture makes it easy to implement Django-style generic actions in Rails by leveraging Rack and ActionController::Metal.

The Rails generator system is got a revamp as well. Instead of monolithic generators that know about all of the Rails frameworks, each generator calls a series of hooks, such as :test_framework and :orm, that plugins can register handlers for. This means that generating a scaffold when using rSpec, DataMapper and Haml will generate a scaffold customized for those plugins.

Agnosticism with jQuery, rSpec, and Data Mapper
The rewritten internals and the new plugin APIs have brought true agnosticism to Rails 3 for all components of the framework. Prefer DataMapper to Active Record? No problem. Want to use jQuery instead of Prototype? Go ahead. Eager to test with rSpec instead of test/unit? You got it.

It’s never been easier to Have It Your Way™ with Rails 3. And at the same time, we’ve made that happen without making using the excellent default stack any more complicated.

Documentation
Rails 3 has had a long development cycle and while that might have lead to some impatience, it has also given book and tutorial authors a chance to catch up and be ready. There’s a wealth of great Rails 3 documentation available already and more is coming shortly.

Rails 3.0 has been designed to work with Ruby 1.8.7, Ruby 1.9.2, and JRuby 1.5.2+.

Gratitude and next steps
I’m personally incredibly proud of this release. I’ve been working on Rails for more than 7 years and the quality of the framework we have today is just astounding. This is only possible as a community effort and Rails 3 has seen so many incredible developers step up and help make this our best release ever (wink). Many thanks to all of you.

We’ll continue to develop Rails 3.0 with fixes and tweaks via the stable branch and Rails 3.1 is already cooking on master.

The release candidate process is progressing as planned. This second candidate has very few changes over the first, which means that unless any blockers are discovered with this release, we’re targeting the final release of Rails 3.0 for this week(!!!).

So please do help us weed out any blockers. Especially in our two new main dependencies: Bundler and ARel. They’ve both progressed into release candidacy for their 1.0 releases and will be sharing the same 1.0-final release date as Rails 3.0.

High off Baltimore Pandemic and Yellow Tops, I believe we promised a release candidate shortly after RailsConf. As things usually go in open source, we gorged ourselves on fixes and improvements instead. But all to your benefit. We’ve had 842 commits by 125 authors since the release of the last beta!

Now it’s time to just say good is good enough, otherwise we could keep on with this forever. So please welcome the Rails 3 release candidate! You install, as always, with gem install rails --pre.

Most of the fixes have been of minor significance, but we did manage to dramatically speed up Rails 3 development and startup speed for larger applications (Basecamp went from insufferable to about 2.3 levels of enjoyment).

Speed is now pretty good across the board except for part of Arel that Active Record now depends on. We’ll be making sure we get performance of Active Record back to at least 2.3 levels before release.

A few more highlights:

Support for the MySQL2 gem, which will take care of MySQL encoding issues on Ruby 1.9.2.

Indulge yourself in the delights of all the glorious details from the commit logs or checkout the slightly less pedantic summaries in the CHANGELOGs.

This release candidate of Rails 3 also concides with the release candidate of Bundler 1.0. Huge strides were made with Bundler and it should both be much faster and have most of the edge cases sawed off.

I’ve said “we’re almost there” so many times that I’m almost exhausted. But really, guys, WE’RE ALMOSTTHERE!!!1

RailsConf 2010 is underway and what better occasion to do the final stage of the Rails 3 beta program. We’re very pleased to announce Rails 3 beta 4, which we’ll be hammering on and tuning during RailsConf.

At the end of RailsConf, we’ll be putting out the release candidate. So if you’re at the conference, and even if you’re not, now is the time to give upgrading a chance or even starting a new app. We’re all responsible for making this release solid, please join the fun.

The 2.3.7 release slipped out the door too hastily. Fixing compatibility with the rails_xss plugin inadvertently forced everyone to use it. Facepalm.

I apologize for wasting a chunk of your day on installing what ought to have been a patch-level update only to find it breaks your app. That’s well out of line with our stable release process and it’s my fault for stepping out of it. I got caught up in a sky-is-falling response to a 2.3.6 bug that affected a handful of users and responded with a fix that exposed a new flaw to nearly all users, despite testing and sanity checking.

Thanks for all your feedback today. We hear you, and yes, a thousand times yes. Every stable release, including point releases, deserves the same methodical drumbeat on its march from git stable to to .pre gem to final gem. Expect no less.

With the 2.3.6 release hot out of the oven, Nathan Weizenbaum began updating HAML to support it. He uncovered a couple of bugs in the HTML-safety changes backported from Rails 3, so we’re cutting a 2.3.7 release to fix them.

If you use the rails_xss plugin for automatic HTML escaping, you should upgrade to Rails 2.3.7 and the latest rails_xss plugin.

If you don’t use the rails_xss plugin yet, now’s the time to start. It’s baked in to Rails 3.

Update: fixing compatibility with the rails_xss plugin broke HTML-safety for apps that don’t use rails_xss. We’re sorry, all: HTML-safety is meant to be opt-in! The fix is available now in 2.3.8.pre1 and will be released shortly.

We’ve released Ruby on Rails 2.3.6: six months of bug fixes, a handful of new features, and a strong bridge to Rails 3.

We deprecated some obscure and ancient features in Rails 2.3.6 so we could cut them entirely from Rails 3. If your app runs on Rails 2.3.6 without deprecation warnings, you’re in good shape for a smooth sail onward.

This slow-cooked dish is brought to you some 87 committers from our all-volunteer kitchen.

Railties

It took longer than we thought, but then again, what doesn’t? This is the second beta release of Rails 3.0 and hopefully our last stop before a release candidate. There are still a handful of known regressions (see the list at the end), but we’ve made huge strides since the last release and so have auxiliary tools like Bundler.

Thanks a million to everyone who’s been working on this. Rails 3 is a mighty big barn and it’s been a joy seeing the community come together to raise it.

Note that Ruby 1.8.7 p248 and p249 has marshaling bugs that crash both Rails 2.3.x and Rails 3.0.0. Ruby 1.9.1 outright segfaults on Rails 3.0.0, so if you want to use Rails 3 with 1.9.x, jump on 1.9.2 trunk for smooth sailing.

Rails 2.3.5 was released over the weekend which provides several bug-fixes and one security fix. It should be fully compatible with all prior 2.3.x releases and can be easily upgraded to with “gem update rails”. The most interesting bits can be summarized in three points.

Improved compatibility with Ruby 1.9

There were a few small bugs preventing full compatibility with Ruby 1.9. However, we wouldn’t be surprised you were already running Rails 2.3.X successfully before these bugs were fixed (they were small).

RailsXss plugin availability

As you may have heard, in Rails 3 we are now automatically escaping all string content in erb (where as before you needed to use “h()” to escape). If you want to have this functionality today you can install Koz’s RailsXss plugin in Rails 2.3.5.

Fixes for the Nokogiri backend for XmlMini

With Rails 2.3 we were given the ability to switch out the default XML parser from REXML to other faster parsers like Nokogiri. There were a few issues with using Nokogiri which are now resolved, so if your application is parsing lots of xml you may want to switch to this faster XML parser.

And that’s the gist of it

Feel free to browse through the commit history if you’d like to see what else has been fixed (but it’s mostly small stuff).

And that’s just the tip of the iceberg. We’ve put together a complete guide for the Rails 2.3 release notes with much more information. Be sure to checkout the section on what was deprecated when you’re ready to upgrade your application.

The past month has seen a flurry of activity getting Rails 2.3 solid. We think we’ve ironed out all the major kinks now, but just to be sure, we’re running one last release candidate before it heads off to the presses. So please take some time to test out this release candidate. If we don’t get any reports of major blockers, we’re going to call this final within a week or two.

We’ve put together a complete guide for the Rails 2.3 release notes with all the information on what’s new, what’s changed, and what’s deprecated.

Rails 2.3 is almost ready for release, but this package is so stock full of amazing new stuff that we’re making dutifully sure that everything works right before we call it official.

So please help us do thorough testing of this release candidate. Lots of the underpinnings changed. Especially the move to Rack. So we need solid testing and will probably have a slightly longer than average release candidate phase to account for that.

But boy will it be worth it. This is one of the most substantial upgrades to Rails in a very long time. A brief rundown of the top hitters:

Templates: Allows your new skeleton Rails application to be built your way with your default stack of gems, configs, and more.

Phusion is on a roll today. Not only did we just get a new Passenger, they’ve also just dropped a new REE (the Ruby patches for copy-on-write) that includes 64-bit support as well as compatibility with OS X and Solaris. They’ve also fitted the excellent RailsBench patches from Stefan Kaes that allows you to tweak the GC settings in Ruby if you need to.

The Phusion team keeps blazing ahead with Passenger and improving it rapidly. They’ve just released version 2.0.5, which includes a few fixes and introduces compatibility with the Rack-based Edge Rails.

At 37signals, we’ve already switched over Ta-da List and are busy working on getting the rest of our suite running on Passenger. It’s just so much easier to deal with and the memory savings you get through REE are a nice cherry on top.

I keep getting a steady stream of success reports from all over the world as well. I’ve even read of a few people getting back into Rails development because Passenger finally took out the inconvenience of deploying.

It’s hard to argue with the usability. I’ve personally been setting up a new server running Ubuntu 8.10 and using Apache 2 with Passenger. The time it took me to go from a fresh install to a complete production setup was ridiculously low. There’s just so much less to worry about.

If you haven’t given Passenger a chance yet, now is definitely the time.

Rails 2.2 is finally done after we cleared the last issues from the release candidate program. This release contains an long list of fixes, improvements, and additions that’ll make everything Rails smoother and better, but we also have a number of star player features to parade this time.

Internationalization by default
The most important is that Rails now includes a full-on internationalization framework and that it’s pre-wired from start. The work of the i18n group has been very impressive and it’s great to see that Rails finally ships with a solution in the box that’s both simple and extensible. Great job, guys!

Stronger etag and last-modified support
We’ve also added much better support for HTTP validators in the form of etag and last-modified. Making it so much easier to skip expensive procesesing if the client already has the latest stuff. This also makes it even easier to use Rails with gateway proxies.

Thread safety and a connection pool
Josh Peek has added thread safety to Rails and Nick Sieger from JRuby worked on getting Active Record a proper connection pool. So now all elements of Rails are thread safe, which is a big boon for the JRuby guys in particular. For C Ruby, we still need a bunch of dependent libraries to go non-blocking before it’ll make much of a difference, but work on that is forth coming.

Ruby 1.9 and JRuby compatibility
Jeremy Kemper has been rocking on both Ruby 1.9 and JRuby compatibility. Rails 2.2 is fully compatible with both, but again, there might be supporting libraries and gems that are not. Again, lots of work is going into making everything else fully compatible as well.

Better API docs, great guides
Finally, the last big push has been with the documentation of Rails. Pratik’s docrails project has made immense progress. Not only are the API docs much improved, but we also have a whole new guides section generated from documentation that now lives with the source. A true community project with lots of contributors. I’m sure both those new and old to Rails will greatly appreciate the strong focus on documentation.

To read about all these features and more in details, checkout the Rails 2.2 release notes — another one of those guides from the docrails project.

How to install
As always, you can install Rails 2.2 through RubyGems. We now require RubyGems 1.3.1, so be sure to update that first: gem update --system

Then you can install Rails: gem install rails

If you’re updating an existing application, you can run rake rails:update to get the latest JavaScript files and scripts.

From all of us to all of you, we hope you enjoy this release. It’s a true pleasure to see Rails make such big steps forward once again. Dig in, have fun, and we’ll be back with Rails 2.3 with even more before you know it.

Rails 2.2 has been baking for long enough now. This is the last taste before the goodies are served. So please install and check it out. See if you can find any regressions or bugs in any of the new stuff, so we can have it all delicious by the time we ring the dinner bell (ok, ok, I’ll put down the food metaphor now).

This release also conciedes with the fact that we’ve branches 2-2-stable, which means that master is now actually targeting Rails 2.3/3.0. There’s also a tag available for this RC as v2.2.1.

Rails 2.2 is almost ready for its final release, but before we christen the gems, we’d like to have everyone test out a release candidate. Rails 2.2 is a major upgrade that includes a wealth of new features and fixes.

Chief inclusions are an internationalization framework, thread safety (including a connection pool for Active Record), easier access to HTTP caching with etags and last modified, compatibility with Ruby 1.9 and JRuby, and a wealth of new documentation.

Mike Gunderloy has compiled an exhaustive list and walk-through of many of the interesting new features for the Rails 2.2 release notes.

Thanks to Git it’s been a lot easier to maintain older branches of the code base, so we’ve taken the opportunity to backport a bunch of bug fixes to the 2.0 branch and here’s the release for that.

The only major issue is that we’ve fixed the REXML DoS vulnerability with a monkey patch that ships in the box. So if you’re on 2.0 and haven’t dealt with the issue already, you can upgrade to 2.0.4 and get it fixed.

Capistrano 2.4.0 is now available. Capistrano is the deployment tool of choice for many Rails programmers, but can be used for much more, allowing you to automate remote tasks using a simple task-oriented framework in Ruby.

Rails 2.1 is now available for general consumption with all the features and fixes we’ve been putting in over the last six months since 2.0. This has been a huge effort by a very wide range of contributors helping to make it happen.

Over the past six months, we’ve had 1,400 contributors creating patches and vetting them. This has resulted in 1,600+ patches. A truly staggering number. And lots of that has made it into this release.

Threat level orange, guys! The release candidate for Rails 2.1 is drawing awfully close, so if you’ve been sitting on a patch that just must make it in now is the time to rise hell or high water to make it so. Once we cut the release candidate, we’ll be loathe to introduce anything but bug fixes to the features already there.

So get in your saddle, cowboy, and make that patch happen. Remember that the party has moved to Github and Lighthouse. Giddiyap!

Capistrano is a utility for managing remote servers and automating remote tasks. It is popularly used to deploy Rails applications (but can do oh, so much more!). Version 2.2.0 is now available (well, it’s released, anyway, you might need to wait for the file to propagate to the gem mirrors).

gem install capistrano

Version 2.2.0 sports the following changes:

FEATURE: Dynamic role definition. The role() method now accepts a block, which should return either a host name, a Capistrano::ServerDefinition object, an array of host names, or an array of Capistrano::ServerDefinition objects. This can be used to describe the servers in a role at runtime.

role :app do
hosts = some_method_that_looks_up_the_current_hosts
hosts[0,3]
end

FEATURE: Alternative server-centric role definitions, using the server() method:

role :app, "server"
role :web, "server"
# the above is the same as this:
server "server", :app, :web

FEATURE: Support for a :max_hosts option in tasks, that restricts the task so that it is only executed in hosts at a time, in chunks. This helps people who use Capistrano with very large numbers of servers, and prevents them running into connection caps and from running out of memory.

task :ping, :max_hosts => 100 do
# anything here will only run against 100 hosts at a time
end
# alternatively, you can pass :max_hosts to the run command itself for
# finer granularity
task :pong do
# this will run on ALL hosts at once
run "something"
# this will run on no more than 100 hosts at a time
run "something-else", :max_hosts => 100
end

ENHANCEMENT: Improved Git support!

ENHANCEMENT: Password prompt support in the Mercurial SCM.

ENHANCEMENT: Implement Bzr#next_revision so that pending changes can be reported correctly, and use checkout —lightweight instead of branch.

ENHANCEMENT: Bring back the :p4sync_flags and :p4client_root variables for perforce SCM.

Additionally, there are several minor bugs and typos that have been fixed. You can see the CHANGELOG for all the gory details.

ActiveMerchant 1.3 has been released. The focus on this latest release was the addition of standardized support for the Address Verification System (AVS) and credit card verification value (CVV2) checks across all gateways which is the latest extraction from Shopify.

AVS information helps reduce fraud by checking the billing address of the customer with the cardholder information on file at the credit card company. CVV2 checks help ensure that the cardholder information has not been stolen from a database of credit card numbers because it is forbidden to record or store CVV2 numbers in any way.

The results of the AVS and CVV2 checks are now available in the response object. ActiveMerchant does all the work of interpreting the information returned from the payment gateways for you and makes the information available in a consistent hash format.

Coinciding with the 1.3 release of ActiveMerchant is the [ActiveMerchant PeepCode PDF](http://peepcode.com/products/activemerchant-pdf) by [Cody Fauser](http://www.codyfauser.com). The PDF goes over the basics of payment processing, making purchases with ActiveMerchant, and security considerations to keep in mind when processing credit cards in your Rails application. The PDF also walks through the development of a sample Rails application that addresses topics such as order pipelines, order state management and the appropriate unit testing a financial application requires. It is definitely a great read if you are curious about payment processing or require payment processing in your application.

Now that we have the big Rails 2.0 release out the door, it’s a lot easier to push out smaller updates more frequently. So that’s what we’re going to do. Rails 2.0.2 contains a bunch of smaller fixes to various bugs, no show-stopping action, just further polish. But it also contains a few new defaults.

SQLite3 is the new default database

Most importantly is SQLite3 as the new database we’ll configure for by default when you run the rails generation command without any specification. This change comes as SQLite3 is simply an easier out of the box experience than MySQL. There’s no fussing with GRANTs and creates, the database is just there. This is especially so under OS X 10.5 Leopard, which ships with SQLite3 and the driver gems preinstalled as part of the development kit.

If you want to preconfigure your database for MySQL (or any of the other adapters), you simply do “rails -d mysql myapp” and everything is the same as before. But if you’re just playing with a new application or building a smallish internal tool, then I strongly recommend having a look at SQLite3. Thanks to the agnostic db/schema.rb, it’s as easy as changing your config/database.yml to switch from SQLite3 to MySQL (or another database) as soon as your load warrants it.

Don’t check for template changes in production mode

New applications will be generated with the following option in their config/environments/production.rb:

config.action_view.cache_template_loading = true

This will stop Rails from constantly doing STAT calls to the file system to check if the file has changed. This can make for a lot of I/O activity, especially if you have lots of partials. If you have very fast disks, this may not matter, but if you’re running off slower disks it can make quite a big difference.

The drawback is that you can no longer just svnup a single template file and see it changed immediately. You’ll have to restart the application servers to make that happen.

Regardless, we feel that this is the better default in a partial-heavy world, but you’re of course always free to change it.

Rails 2.0.2 is a drop-in replacement for Rails 2.0

To upgrade, just do “gem install rails” (if the gems are still not propagated, use —source http://gems.rubyonrails.org) or use the new rel_2-0-2 tag.

Changed the default database from mysql to sqlite3, so now running “rails myapp” will have a config/database.yml that’s setup for SQLite3 (which in OS X Leopard is installed by default, so is the gem, so everything Just Works with no database configuration at all). To get a Rails application preconfigured for MySQL, just run “rails -d mysql myapp” [DHH]

Turned on ActionView::Base.cache_template_loading by default in config/environments/production.rb to prevent file system stat calls for every template loading to see if it changed (this means that you have to restart the application to see template changes in production mode) [DHH]

Rails 2.0 is finally finished after about a year in the making. This is a fantastic release that’s absolutely stuffed with great new features, loads of fixes, and an incredible amount of polish. We’ve even taken a fair bit of cruft out to make the whole package more coherent and lean.

What a milestone for Ruby on Rails as well. I’ve personally been working on this framework for about four and a half years and we have contributors who’ve been around for almost as long as well. It’s really satisfying to see how far we’ve come in that period of time. That we’ve proven the initial hype worthy, that we’ve been able to stick with it and continue to push the envelope.

Before jumping into the breakdown of features, I’d just like to extend my deep gratitude towards everyone who helped make this release possible. From the stable of merry men in the Rails core to the hundreds of contributors who got a patch applied to everyone who participated in the community over the year. This release is a triumph for large-scale open source development and you can all be mighty proud of the role you played. Cheers!

With the touchy-feely stuff out of the way, let’s dig into the feast and look at just a sliver of what’s new:

Action Pack: Resources

This is where the bulk of the action for 2.0 has gone. We’ve got a slew of improvements to the RESTful lifestyle. First, we’ve dropped the semicolon for custom methods instead of the regular slash. So /people/1;edit is now /people/1/edit. We’ve also added the namespace feature to routing resources that makes it really easy to confine things like admin interfaces:

Which will give you named routes like inventory_admin_products_url and admin_product_tags_url. To keep track of this named routes proliferation, we’ve added the “rake routes” task, which will list all the named routes created by routes.rb.

We’ve also instigated a new convention that all resource-based controllers will be plural by default. This allows a single resource to be mapped in multiple contexts and still refer to the same controller. Example:

Alongside the improvements for resources come improvements for multiview. We already have #respond_to, but we’ve taken it a step further and made it dig into the templates. We’ve separated the format of the template from its rendering engine. So show.rhtml now becomes show.html.erb, which is the template that’ll be rendered by default for a show action that has declared format.html in its respond_to. And you can now have something like show.csv.erb, which targets text/csv, but also uses the default ERB renderer.

So the new format for templates is action.format.renderer. A few examples:

show.erb: same show template for all formats

index.atom.builder: uses the Builder format, previously known as rxml, to render an index action for the application/atom+xml mime type

edit.iphone.haml: uses the custom HAML template engine (not included by default) to render an edit action for the custom Mime::IPHONE format

Speaking of the iPhone, we’ve made it easier to declare “fake” types that are only used for internal routing. Like when you want a special HTML interface just for an iPhone. All it takes is something like this:

You’re encouraged to declare your own mime-type aliases in the config/initializers/mime_types.rb file. This file is included by default in all new applications.

Action Pack: Record identification

Piggy-backing off the new drive for resources are a number of simplifications for controller and view methods that deal with URLs. We’ve added a number of conventions for turning model classes into resource routes on the fly. Examples:

# person is a Person object, which by convention will
# be mapped to person_url for lookup
redirect_to(person)
link_to(person.name, person)
form_for(person)

Action Pack: HTTP Loving

As you might have gathered, Action Pack in Rails 2.0 is all about getting closer with HTTP and all its glory. Resources, multiple representations, but there’s more. We’ve added a new module to work with HTTP Basic Authentication, which turns out to be a great way to do API authentication over SSL. It’s terribly simple to use. Here’s an example (there are more in ActionController::HttpAuthentication):

We’ve also made it much easier to structure your JavaScript and stylesheet files in logical units without getting clobbered by the HTTP overhead of requesting a bazillion files. Using javascript_include_tag(:all, :cache => true) will turn public/javascripts/.js into a single public/javascripts/all.js file in production, while still keeping the files separate in development, so you can work iteratively without clearing the cache.

Along the same lines, we’ve added the option to cheat browsers who don’t feel like pipelining requests on their own. If you set ActionController::Base.asset_host = “assets%d.example.com”, we’ll automatically distribute your asset calls (like image_tag) to asset1 through asset4. That allows the browser to open many more connections at a time and increases the perceived speed of your application.

Action Pack: Security

Making it even easier to create secure applications out of the box is always a pleasure and with Rails 2.0 we’re doing it from a number of fronts. Most importantly, we now ship we a built-in mechanism for dealing with CRSF attacks. By including a special token in all forms and Ajax requests, you can guard from having requests made from outside of your application. All this is turned on by default in new Rails 2.0 applications and you can very easily turn it on in your existing applications using ActionController::Base.protect_from_forgery (see ActionController::RequestForgeryProtection for more).

We’ve also made it easier to deal with XSS attacks while still allowing users to embed HTML in your pages. The old TextHelper#sanitize method has gone from a black list (very hard to keep secure) approach to a white list approach. If you’re already using sanitize, you’ll automatically be granted better protection. You can tweak the tags that are allowed by default with sanitize as well. See TextHelper#sanitize for details.

Finally, we’ve added support for HTTP only cookies. They are not yet supported by all browsers, but you can use them where they are.

Action Pack: Exception handling

Lots of common exceptions would do better to be rescued at a shared level rather than per action. This has always been possible by overwriting rescue_action_in_public, but then you had to roll out your own case statement and call super. Bah. So now we have a class level macro called rescue_from, which you can use to declaratively point certain exceptions to a given action. Example:

The default session store in Rails 2.0 is now a cookie-based one. That means sessions are no longer stored on the file system or in the database, but kept by the client in a hashed form that can’t be forged. This makes it not only a lot faster than traditional session stores, but also makes it zero maintenance. There’s no cron job needed to clear out the sessions and your server won’t crash because you forgot and suddenly had 500K files in tmp/session.

This setup works great if you follow best practices and keep session usage to a minimum, such as the common case of just storing a user_id and a the flash. If, however, you are planning on storing the nuclear launch codes in the session, the default cookie store is a bad deal. While they can’t be forged (so is_admin = true is fine), their content can be seen. If that’s a problem for your application, you can always just switch back to one of the traditional session stores (but first investigate that requirement as a code smell).

Action Pack: New request profiler

Figuring out where your bottlenecks are with real usage can be tough, but we just made it a whole lot easier with the new request profiler that can follow an entire usage script and report on the aggregate findings. You use it like this:

And you get a thorough breakdown in HTML and text on where time was spent and you’ll have a good idea on where to look for speeding up the application.

Action Pack: Miscellaneous

Also of note is AtomFeedHelper, which makes it even simpler to create Atom feeds using an enhanced Builder syntax. Simple example:

# index.atom.builder:
atom_feed do |feed|
feed.title("My great blog!")
feed.updated((@posts.first.created_at))
for post in @posts
feed.entry(post) do |entry|
entry.title(post.title)
entry.content(post.body, :type => 'html')
entry.author do |author|
author.name("DHH")
end
end
end
end

We’ve made a number of performance improvements, so asset tag calls are now much cheaper and we’re caching simple named routes, making them much faster too.

Finally, we’ve kicked out in_place_editor and autocomplete_for into plugins that live on the official Rails SVN.

Active Record: Performance

Active Record has seen a gazillion fixes and small tweaks, but it’s somewhat light on big new features. Something new that we have added, though, is a very simple Query Cache, which will recognize similar SQL calls from within the same request and return the cached result. This is especially nice for N+1 situations that might be hard to handle with :include or other mechanisms. We’ve also drastically improved the performance of fixtures, which makes most test suites based on normal fixture use be 50-100% faster.

Active Record: Sexy migrations

There’s a new alternative format for declaring migrations in a slightly more efficient format. Before you’d write:

The fixtures in Active Record has taken a fair amount of flak lately. One of the key points in that criticism has been the work with declaring dependencies between fixtures. Having to relate fixtures through the ids of their primary keys is no fun. That’s been addressed now and you can write fixtures like this:

As you can see, it’s no longer necessary to declare the ids of the fixtures and instead of using seller_id to refer to the relationship, you just use seller and the name of the fixture.

Active Record: XML in, JSON out

Active Record has supported serialization to XML for a while. In 2.0 we’ve added deserialization too, so you can say Person.new.from_xml(“David”) and get what you’d expect. We’ve also added serialization to JSON, which supports the same syntax as XML serialization (including nested associations). Just do person.to_json and you’re ready to roll.

Active Record: Shedding some weight

To make Active Record a little leaner and meaner, we’ve removed the acts_as_XYZ features and put them into individual plugins on the Rails SVN repository. So say you’re using acts_as_list, you just need to do ./script/plugin install acts_as_list and everything will move along like nothing ever happened.

A little more drastic, we’ve also pushed all the commercial database adapters into their own gems. So Rails now only ships with adapters for MySQL, SQLite, and PostgreSQL. These are the databases that we have easy and willing access to test on. But that doesn’t mean the commercial databases are left out in the cold. Rather, they’ve now been set free to have an independent release schedule from the main Rails distribution. And that’s probably a good thing as the commercial databases tend to require a lot more exceptions and hoop jumping on a regular basis to work well.

The commercial database adapters now live in gems that all follow the same naming convention: activerecord-XYZ-adapter. So if you gem install activerecord-oracle-adapter, you’ll instantly have Oracle available as an adapter choice in all the Rails applications on that machine. You won’t have to change a single line in your applications to take use of it.

That also means it’ll be easier for new database adapters to gain traction in the Rails world. As long as you package your adapter according to the published conventions, users just have to install the gem and they’re ready to roll.

Active Record: with_scope with a dash of syntactic vinegar

ActiveRecord::Base.with_scope has gone protected to discourage people from misusing it in controllers (especially in filters). Instead, it’s now encouraged that you only use it within the model itself. That’s what it was designed for and where it logically remains a good fit. But of course, this is all about encouraging and discouraging. If you’ve weighed the pros and the cons and still want to use with_scope outside of the model, you can always call it through .send(:with_scope).

ActionWebService out, ActiveResource in

It’ll probably come as no surprise that Rails has picked a side in the SOAP vs REST debate. Unless you absolutely have to use SOAP for integration purposes, we strongly discourage you from doing so. As a naturally extension of that, we’ve pulled ActionWebService from the default bundle. It’s only a gem install actionwebservice away, but it sends an important message none the less.

At the same time, we’ve pulled the new ActiveResource framework out of beta and into the default bundle. ActiveResource is like ActiveRecord, but for resources. It follows a similar API and is configured to Just Work with Rails applications using the resource-driven approach. For example, a vanilla scaffold will be accessible by ActiveResource.

ActiveSupport

There’s not all that much new in ActiveSupport. We’ve a host of new methods like Array#rand for getting a random element from an array, Hash#except to filter down a hash from undesired keys and lots of extensions for Date. We also made testing a little nicer with assert_difference. Short of that, it’s pretty much just fixes and tweaks.

Action Mailer

This is a very modest update for Action Mailer. Besides a handful of bug fixes, we’ve added the option to register alternative template engines and assert_emails to the testing suite, which works like this:

Assert number of emails delivered within a block:
assert_emails 1 do
post :signup, :name => ‘Jonathan’
end

Rails: The debugger is back

To tie it all together, we have a stream of improvements for Rails in general. My favorite amongst these is the return of the breakpoint in form of the debugger. It’s a real debugger too, not just an IRB dump. You can step back and forth, list your current position, and much more. It’s all coming from the gracious note of the ruby-debug gem. So you’ll have to install that for the new debugger to work.

To use the debugger, you just install the gem, put “debugger” somewhere in your application, and then start the server with —debugger or -u. When the code executes the debugger command, you’ll have it available straight in the terminal running the server. No need for script/breakpointer or anything else. You can use the debugger in your tests too.

Rails: Clean up your environment

Before Rails 2.0, config/environment.rb files every where would be clogged with all sorts of one-off configuration details. Now you can gather those elements in self-contained files and put them under config/initializers and they’ll automatically be loaded. New Rails 2.0 applications ship with two examples in form of inflections.rb (for your own pluralization rules) and mime_types.rb (for your own mime types). This should ensure that you need to keep nothing but the default in config/environment.rb.

Rails: Easier plugin order

Now that we’ve yanked out a fair amount of stuff from Rails and into plugins, you might well have other plugins that depend on this functionality. This can require that you load, say, acts_as_list before your own acts_as_extra_cool_list plugin in order for the latter to extend the former.

Before, this required that you named all your plugins in config.plugins. Major hassle when all you wanted to say was “I only care about acts_as_list being loaded before everything else”. Now you can do exactly that with config.plugins = [ :acts_as_list, :all ].

And hundreds upon hundreds of other improvements

What I’ve talked about above is but a tiny sliver of the full 2.0 package. We’ve got literally hundreds of bug fixes, tweaks, and feature enhancements crammed into Rails 2.0. All this coming off the work of tons of eager contributors working tirelessly to improve the framework in small, but important ways.

I encourage you to scourger the CHANGELOGs and learn more about all that changed.

So how do I upgrade?

If you want to move your application to Rails 2.0, you should first move it to Rails 1.2.6. That’ll include deprecation warnings for most everything we yanked out in 2.0. So if your application runs fine on 1.2.6 with no deprecation warnings, there’s a good chance that it’ll run straight up on 2.0. Of course, if you’re using, say, pagination, you’ll need to install the classic_pagination plugin. If you’re using Oracle, you’ll need to install the activerecord-oracle-adapter gem. And so on and so forth for all the extractions.

So how do I install?

To install through gems, do:

gem install rails -y

…if you’re having trouble with that (gem not found), just grab gems from our own repository in the meanwhile:

gem install rails -y —source http://gems.rubyonrails.org

To try it from an SVN tag, use (you may need to run this command twice depending on your current Rails version):

rake rails:freeze:edge TAG=rel_2-0-1

Note: It’s 2.0.1 because we found a small issue just after we pushed 2.0.0.

After another batch of fixes, tweaks, and buckets of polish, we’ve prepared the hopefully last step before 2.0 can go final: Release Candidate 2. If nothing major pops up, expect the final version to land within the next week or two at the most.

As usual, we got the latest gems on the gems.rubyonrails.org server and there’s a RC2 tag as well. Please put this final test through the ringer so we can get a clean 2.0.0 final release.

We’ve been taking our sweet time, but now it really is almost there. We’ve just pushed new beta gems to gems.rubyonrails.org and created the rel_2-0-0_RC1 tag. So this is shaping up to be the last chance to raise concerns for Rails 2.0 before we go final in oh-so-shortly.

So please give it a spin. First, upgrade to 1.2.5 if you haven’t already. Fix all the deprecation warnings you see. Then try to jump on Rails 2.0 and see if it runs. If it doesn’t, and you think it’s not because of something you did wrong, please create a ticket.

We’re going to be running this release candidate phase over the next couple of weeks, give or take depending on how many issues are raised.

New versions of the JavaScript libraries that ship with Rails, Prototype 1.6.0 and script.aculo.us 1.8.0, have been released. You can find out about the numerous changes on the Prototype blog and on mir.aculo.us. If you’re running Edge Rails, just svn up and run rake rails:update:javascripts to install the latest versions into your application automatically.

Also of note: Christophe Porteneuve’s Prototype & script.aculo.us book is now out of beta and available for purchase from the Pragmatic Programmers. It’s up-to-date with all of the new features in both libraries, so be sure to check it out if you’re using Prototype and script.aculo.us in your applications.

After a much larger delay than I would have liked, Capistrano 2.1 is now available! (Capistrano is a utility for executing commands on multiple remote machines in parallel, and is the tool of choice for many Rails developers for automating deployment.) There is a lot going on in this release, including some pretty exciting changes. As ever, install it via RubyGems with:

gem install capistrano

Here’s what’s new, roughly in order of magnitude:

No default PTY. Prior to 2.1, Capistrano would request a pseudo-tty for each command that it executed. This had the side-effect of causing the profile scripts for the user to not be loaded. Well, no more! As of 2.1, Capistrano no longer requests a pty on each command, which means your .profile (or .bashrc, or whatever) will be properly loaded on each command! Note, however, that some have reported on some systems, when a pty is not allocated, some commands will go into non-interactive mode automatically. If you’re not seeing commands prompt like they used to, like svn or passwd, you can return to the previous behavior by adding the following line to your capfile:

default_run_options[:pty] = true

Disable sh wrapping. Some shared hosts do not allow the POSIX shell to be used to execute arbitrary commands, which is what Capistrano has done since 2.0. If you’re on such a host, you can add the following line to your capfile:

default_run_options[:shell] = false

Capistrano will then run the command directly, rather than wrapping it in an “sh -c” command. Note, though, that this means that your own user shell on the remote hosts must be POSIX compatible, or you’ll get cryptic errors.

Git SCM support. Many thanks to Garry Dolley, Geoffrey Grosenbach, and Scott Chacon for their work on the new Git SCM module for Capistrano. If you’re a user of Git, you can now do:

set :scm, :git

Accurev SCM support. Thanks to Doug Barth, all you Accurev users can now enjoy Capistrano, too. Just do:

set :scm, :accurev

Rails’ Plugin Support. Capfile’s generated via the “capify” utility will now include a line that will autoload all recipes from vendor/plugins/*/recipes/*.rb. If you want this feature and you’ve already got a Capfile (and you don’t mind losing any changes you might have made to your Capfile), you can delete the Capfile and re-run “capify .”. Or, you can just add the following line to your Capfile, before the line that loads ‘config/deploy’:

Dir['vendor/plugins/*/recipes/*.rb'].each { |plugin| load(plugin) }

Windows-safe reads. Any time Capistrano needs to read a file’s contents, it will now use the “b” flag, so that binary reads on Windows do not corrupt the file.

Cap shell and sudo. The Capistrano shell now properly recognizes sudo commands and prompts for the password correctly.

Use `match’ to check dependencies. There is a new remote dependency method for deploy:check: “match”. You can now look for arbitrary regular expressions in the output of various commands to see if things are set up correctly:

depend :remote, :match, "rake -V", /version 0\.7/

Namespaces#top. Sometimes you’ll find yourself wanting to execute a task from within another task, but the parent namespace of the target task is conflicting with a similarly-named namespace, and things are breaking. You can now use the “top” method to jump to the top of the namespace hierarchy:

namespace :apache do
namespace :deploy do
task :restart do
run "restart apache"
top.deploy.restart
end
end
end

Other changes. There are lots of other, smaller bug fixes and changes, too:

Default to 0664 instead of 0660 on upload.

Fix deploy:pending to query SCM for the subsequent revision so that it does not include the last deployed change.

This release contains additional deprecation notices, security fixes and some minor performance improvements. All users of 1.2.3 are advised to upgrade.

Deprecation Notices

If you intend to upgrade to 2.0 you should run your tests to and fix any errors that are displayed. The warnings will become errors with the release of 2.0.

If you’re using RESTful routing, pay special attention to the changes to route generation and recognition. The previous use of the semicolon in URLs has been replaced with a regular /. For instance /person/1;edit has become /person/1/edit. This change was made as several libraries, including mongrel, mistakenly treated semi-colons as query string seperators and some browsers and http libraries misbehaved.

Your old ;-based URLs will be continued to be recognized, though. They’re just no longer generated.

Security Enhancements

1.2.4 fixes several potential security issues:

Session fixation attacks are mitigated by removing support for URL-based sessions

Changed the JSON encoding algorithms to avoid otential XSS issues when using ActiveRecord::Base#to_json

Potential Security and performance problems with XmlSimple have been fixed by disabling certain dangerous options by default.

Behold, behold, Rails 2.0 is almost here. But before we can slap on the final stamp, we’re going to pass through a couple of trial release phases. The first is this preview release, which allows you to sample the goodies in their almost finished state.

We might change a few things or add something else, but by and large, this is how Rails 2.0 is going to look and feel. After this release have had a chance to be tried out, we’re going to move to a release candidate or two (or three, depending on how many we need). Then, the final release.

Before the release of 2.0, we’re also going to be putting out 1.2.4, which will include a variety of bug fixes and the last deprecation warnings to get you ready for upgrading an existing application to 2.0 standards.

Enough about process. Let me tell you a little bit about what’s new in Rails 2.0:

Action Pack: Resources

This is where the bulk of the action for 2.0 has gone. We’ve got a slew of improvements to the RESTful lifestyle. First, we’ve dropped the semicolon for custom methods instead of the regular slash. So /people/1;edit is now /people/1/edit. We’ve also added the namespace feature to routing resources that makes it really easy to confine things like admin interfaces:

Which will give you named routes like inventory_admin_products_url and admin_product_tags_url. To keep track of this named routes proliferation, we’ve added the “rake routes” task, which will list all the named routes created by routes.rb.

We’ve also instigated a new convention that all resource-based controllers will be plural by default. This allows a single resource to be mapped in multiple contexts and still refer to the same controller. Example:

Alongside the improvements for resources come improvements for multiview. We already have #respond_to, but we’ve taken it a step further and made it dig into the templates. We’ve separated the format of the template from its rendering engine. So show.rhtml now becomes show.html.erb, which is the template that’ll be rendered by default for a show action that has declared format.html in its respond_to. And you can now have something like show.csv.erb, which targets text/csv, but also uses the default ERB renderer.

So the new format for templates is action.format.renderer. A few examples:

show.erb: same show template for all formats

index.atom.builder: uses the Builder format, previously known as rxml, to render an index action for the application/atom+xml mime type

edit.iphone.haml: uses the custom HAML template engine (not included by default) to render an edit action for the custom Mime::IPHONE format

Speaking of the iPhone, we’ve made it easier to declare “fake” types that are only used for internal routing. Like when you want a special HTML interface just for an iPhone. All it takes is something like this:

You’re encouraged to declare your own mime-type aliases in the config/initializers/mime_types.rb file. This file is included by default in all new applications.

Action Pack: Record identification

Piggy-backing off the new drive for resources are a number of simplifications for controller and view methods that deal with URLs. We’ve added a number of conventions for turning model classes into resource routes on the fly. Examples:

# person is a Person object, which by convention will
# be mapped to person_url for lookup
redirect_to(person)
link_to(person.name, person)
form_for(person)

Action Pack: HTTP Loving

As you might have gathered, Action Pack in Rails 2.0 is all about getting closer with HTTP and all its glory. Resources, multiple representations, but there’s more. We’ve added a new module to work with HTTP Basic Authentication, which turns out to be a great way to do API authentication over SSL. It’s terribly simple to use. Here’s an example (there are more in ActionController::HttpAuthentication):

We’ve also made it much easier to structure your JavaScript and stylesheet files in logical units without getting clobbered by the HTTP overhead of requesting a bazillion files. Using javascript_include_tag(:all, :cache => true) will turn public/javascripts/.js into a single public/javascripts/all.js file in production, while still keeping the files separate in development, so you can work iteratively without clearing the cache.

Along the same lines, we’ve added the option to cheat browsers who don’t feel like pipelining requests on their own. If you set ActionController::Base.asset_host = “assets%d.example.com”, we’ll automatically distribute your asset calls (like image_tag) to asset1 through asset4. That allows the browser to open many more connections at a time and increases the perceived speed of your application.

Action Pack: Security

Making it even easier to create secure applications out of the box is always a pleasure and with Rails 2.0 we’re doing it from a number of fronts. Most importantly, we now ship we a built-in mechanism for dealing with CRSF attacks. By including a special token in all forms and Ajax requests, you can guard from having requests made from outside of your application. All this is turned on by default in new Rails 2.0 applications and you can very easily turn it on in your existing applications using ActionController::Base.protect_from_forgery (see ActionController::RequestForgeryProtection for more).

We’ve also made it easier to deal with XSS attacks while still allowing users to embed HTML in your pages. The old TextHelper#sanitize method has gone from a black list (very hard to keep secure) approach to a white list approach. If you’re already using sanitize, you’ll automatically be granted better protection. You can tweak the tags that are allowed by default with sanitize as well. See TextHelper#sanitize for details.

Finally, we’ve added support for HTTP only cookies. They are not yet supported by all browsers, but you can use them where they are.

Action Pack: Exception handling

Lots of common exceptions would do better to be rescued at a shared level rather than per action. This has always been possible by overwriting rescue_action_in_public, but then you had to roll out your own case statement and call super. Bah. So now we have a class level macro called rescue_from, which you can use to declaratively point certain exceptions to a given action. Example:

Also of note is AtomFeedHelper, which makes it even simpler to create Atom feeds using an enhanced Builder syntax. Simple example:

# index.atom.builder:
atom_feed do |feed|
feed.title("My great blog!")
feed.updated((@posts.first.created_at))
for post in @posts
feed.entry(post) do |entry|
entry.title(post.title)
entry.content(post.body, :type => 'html')
entry.author do |author|
author.name("DHH")
end
end
end
end

We’ve made a number of performance improvements, so asset tag calls are now much cheaper and we’re caching simple named routes, making them much faster too.

Finally, we’ve kicked out in_place_editor and autocomplete_for into plugins that live on the official Rails SVN.

Active Record: Performance

Active Record has seen a gazillion fixes and small tweaks, but it’s somewhat light on big new features. Something new that we have added, though, is a very simple Query Cache, which will recognize similar SQL calls from within the same request and return the cached result. This is especially nice for N+1 situations that might be hard to handle with :include or other mechanisms. We’ve also drastically improved the performance of fixtures, which makes most test suites based on normal fixture use be 50-100% faster.

Active Record: Sexy migrations

There’s a new alternative format for declaring migrations in a slightly more efficient format. Before you’d write:

Active Record has supported serialization to XML for a while. In 2.0 we’ve added deserialization too, so you can say Person.new.from_xml(“David”) and get what you’d expect. We’ve also added serialization to JSON, which supports the same syntax as XML serialization (including nested associations). Just do person.to_json and you’re ready to roll.

Active Record: Shedding some weight

To make Active Record a little leaner and meaner, we’ve removed the acts_as_XYZ features and put them into individual plugins on the Rails SVN repository. So say you’re using acts_as_list, you just need to do ./script/plugin install acts_as_list and everything will move along like nothing ever happened.

A little more drastic, we’ve also pushed all the commercial database adapters into their own gems. So Rails now only ships with adapters for MySQL, SQLite, and PostgreSQL. These are the databases that we have easy and willing access to test on. But that doesn’t mean the commercial databases are left out in the cold. Rather, they’ve now been set free to have an independent release schedule from the main Rails distribution. And that’s probably a good thing as the commercial databases tend to require a lot more exceptions and hoop jumping on a regular basis to work well.

The commercial database adapters now live in gems that all follow the same naming convention: activerecord-XYZ-adapter. So if you gem install activerecord-oracle-adapter, you’ll instantly have Oracle available as an adapter choice in all the Rails applications on that machine. You won’t have to change a single line in your applications to take use of it.

That also means it’ll be easier for new database adapters to gain traction in the Rails world. As long as you package your adapter according to the published conventions, users just have to install the gem and they’re ready to roll.

Active Record: with_scope with a dash of syntactic vinegar

ActiveRecord::Base.with_scope has gone protected to discourage people from misusing it in controllers (especially in filters). Instead, it’s now encouraged that you only use it within the model itself. That’s what it was designed for and where it logically remains a good fit. But of course, this is all about encouraging and discouraging. If you’ve weighed the pros and the cons and still want to use with_scope outside of the model, you can always call it through .send(:with_scope).

ActionWebService out, ActiveResource in

It’ll probably come as no surprise that Rails has picked a side in the SOAP vs REST debate. Unless you absolutely have to use SOAP for integration purposes, we strongly discourage you from doing so. As a naturally extension of that, we’ve pulled ActionWebService from the default bundle. It’s only a gem install actionwebservice away, but it sends an important message none the less.

At the same time, we’ve pulled the new ActiveResource framework out of beta and into the default bundle. ActiveResource is like ActiveRecord, but for resources. It follows a similar API and is configured to Just Work with Rails applications using the resource-driven approach. For example, a vanilla scaffold will be accessible by ActiveResource.

ActiveSupport

There’s not all that much new in ActiveSupport. We’ve a host of new methods like Array#rand for getting a random element from an array, Hash#except to filter down a hash from undesired keys and lots of extensions for Date. We also made testing a little nicer with assert_difference. Short of that, it’s pretty much just fixes and tweaks.

Action Mailer

This is a very modest update for Action Mailer. Besides a handful of bug fixes, we’ve added the option to register alternative template engines and assert_emails to the testing suite, which works like this:

Assert number of emails delivered within a block:
assert_emails 1 do
post :signup, :name => ‘Jonathan’
end

Rails: The debugger is back

To tie it all together, we have a stream of improvements for Rails in general. My favorite amongst these is the return of the breakpoint in form of the debugger. It’s a real debugger too, not just an IRB dump. You can step back and forth, list your current position, and much more. It’s all coming from the gracious note of the ruby-debug gem. So you’ll have to install that for the new debugger to work.

To use the debugger, you just install the gem, put “debugger” somewhere in your application, and then start the server with —debugger or -u. When the code executes the debugger command, you’ll have it available straight in the terminal running the server. No need for script/breakpointer or anything else. You can use the debugger in your tests too.

Rails: Clean up your environment

Before Rails 2.0, config/environment.rb files every where would be clogged with all sorts of one-off configuration details. Now you can gather those elements in self-contained files and put them under config/initializers and they’ll automatically be loaded. New Rails 2.0 applications ship with two examples in form of inflections.rb (for your own pluralization rules) and mime_types.rb (for your own mime types). This should ensure that you need to keep nothing but the default in config/environment.rb.

Rails: Easier plugin order

Now that we’ve yanked out a fair amount of stuff from Rails and into plugins, you might well have other plugins that depend on this functionality. This can require that you load, say, acts_as_list before your own acts_as_extra_cool_list plugin in order for the latter to extend the former.

Before, this required that you named all your plugins in config.plugins. Major hassle when all you wanted to say was “I only care about acts_as_list being loaded before everything else”. Now you can do exactly that with config.plugins = [ :acts_as_list, :all ].

And hundreds upon hundreds of other improvements

What I’ve talked about above is but a tiny sliver of the full 2.0 package. We’ve got literally hundreds of bug fixes, tweaks, and feature enhancements crammed into Rails 2.0. All this coming off the work of tons of eager contributors working tirelessly to improve the framework in small, but important ways.

I encourage you to scourger the CHANGELOGs and learn more about all that changed.

So how do I upgrade?

If you want to move your application to Rails 2.0, you should first move it to Rails 1.2.3. That’ll include deprecation warnings for most everything we yanked out in 2.0. So if your application runs fine on 1.2.3 with no deprecation warnings, there’s a good chance that it’ll run straight up on 2.0. Of course, if you’re using, say, pagination, you’ll need to install the classic_pagination plugin. If you’re using Oracle, you’ll need to install the activerecord-oracle-adapter gem. And so on and so forth for all the extractions.

To install the preview release through gems, do:

gem install rails —source http://gems.rubyonrails.org

To try it from an SVN tag, use:

rake rails:freeze:edge TAG=rel_2-0-0_PR

We’ll also be putting out Rails 1.2.4 shortly which will include a few more deprecations to warn you in time for 2.0.

In any case, as I explained in the beginning, this is a preview release. Use it to get a feel for 2.0. See where your currently application might need tweaks. And try creating a new application from scratch to see the new defaults. In a few weeks we’ll get on with the release candidates.

Thanks to everyone who’ve been involved with the development of Rails 2.0. We’ve been working on this for more than six months and it’s great finally to be able to share it with a larger audience. Enjoy!

Since the last preview release (number four, version 1.99.3), the changes are primarily bug fixes, but the following featureish modifications snuck in, too:

The uploader has added a tiny bit of sleep to prevent the CPU from going bonkers during uploads.

You can specify the $CAPISTRANO:HOST$ placeholder in the filenames that you give to “put”, and it will be replaced with the actual host that the file is being uploaded to.

Also, some people reported SFTP uploads were hanging for them. If this happens to you, try adding the following line to the top of your recipe file:

set :synchronous_connect, true

That will cause connections to the servers to be established serially, rather than in parallel, so if you’ve got a lot of servers that you are connecting to, it might make things a bit time-consuming. However, this appeared to work around the hanging SFTP issue.

You can read the complete changelog here. If you are using Capistrano at all, please also consider joining the mailing list, it’s a great place to share tips and report issues.

KNOWNISSUES

Yes, there are a few of these. Two are of immediate significance:

If you try to use the ‘put’ command to upload a file to two or more hosts via a gateway, you run a good chance of encountering “corrupted mac” errors. This is due to design flaws in Net::SSH and Net::SFTP, and (to my knowledge) cannot be worked around. The current best practice is to upload to a single host, and then use scp or rsync from the remote hosts to pull the file.

A very few people have reported commands hanging inexplicably and infrequently. I suspect this is also due to flaws in Net::SSH, but I’m not certain yet.

The Haml team recently announced the release of Haml 1.7, which is an alternative markup system that you can use in Rails, instead of the default ERb-based markup. Version 1.7 is significantly faster than previous releases (and is almost as fast as Rails’ default system, now!). There are a few other new features, too: read all about it in the release notes. Great work!

Synchronously instantiate the gateway to prevent it being instantiated multiple times.

Use “which” instead of "test -p to test whether a command exists on the path.

The :hosts and :roles keys can now accept lambdas, to lazily select which hosts or roles a task uses.

Versions of Net::SSH prior to 1.1.0 work with Capistrano again.

Variable accesses are now thread safe.

The deployment code is now locale-independent, so that the revision is parsed correctly even if your computer is using a non-English locale.

You can now pass :on_error => :continue when defining a task, so that any connection or command errors that occur during the task’s execution will be ignored, allowing the task (and subsequent tasks) to continue.

So, give it a go. Try it out. Post your feedback to the Capistrano mailing list. I’d love to release cap2 final next week!

P.S. If you are on a Windows machine, and you get Zlib errors trying to install the Capistrano gem, try this. Find the rubygems/package.rb file (wherever it happens to be in your Ruby installation), open it up, and find the zipped_stream method. Then, replace it, wholesale, with the following:

Capistrano is a utility for automating the execution of tasks on one or more remote machines. You can read all about it at www.capify.org.

To install Preview #3, you’ll need to grab it from the Rails beta gem server:

gem install -s http://gems.rubyonrails.org capistrano

Accompanying PR3 is a new page of documentation on the capify.org site: Capistrano Basics. This walks you through the major features of Capistrano, but does not touch on deployment. This makes it a great introduction for those wanting to use Capistrano in non-deployment scenarios.

Preview #3 includes the following changes and enchancements:

Feature: Mercurial and CVS are now supported out of the box. Just set your :scm variable to :mercurial or :cvs, like so:

set :scm, :mercurial
# or
set :scm, :cvs

Thanks to Tobias Luetke and Matthew Elder for the Mercurial module, and Brian Phillips for the CVS module.

Feature: There is now a :default_environment variable, which is a hash that can be used to set environment variables that should be present for all commands that are executed. For instance:

Feature: All commands are now explicitly invoked via “sh”, which means that even if your default user shell is non-POSIX (e.g., tcsh, csh, etc.), you can use Capistrano just fine. Note that if you were using tcsh or csh syntax in your Capistrano scripts, you now need to set the :default_shell variable to use your (non-POSIX) shell of choice:

set :default_shell, "/usr/bin/tcsh"

Feature: You can declare empty roles, and Capistrano won’t complain. This is useful for predeclaring roles that need to exist (because task definitions depend on them), but which might not have any servers in them (depending on runtime conditions).

Feature: A username and port specified with the server definition (e.g., “fred@some.server.com:1234”) now take precedence over the :username and :port settings in the ssh_options hash, rather than the other way around. This lets you set a general default via ssh_options, and override on a per-server basis in the server definitions themselves.

There are several other minor changes and fixes as well; you can read the CHANGELOG for all the gory details.

(It’ll show up as version 1.99.0; the 1.99.x series will be used as the preview releases for 2.0)

For those of you late to the party, Capistrano is a utility for executing remote commands in parallel on multiple remote servers. It is ideal for system administration, and for deploying web applications.

Note, though, that this release is not entirely backwards compatible with Capistrano 1.x, so you may need to massage your recipes a little to make them work smoothly under the new version. In order to make the upgrade process as smooth as possible, I’ve begun compiling a few documents to point out new features, gotchas, and upgrade paths:

Like Capistrano 2.0, the new www.capify.org website is still a bit rough in spots, and will see more documentation appearing over the next few weeks. If you have any feedback for either Capistrano 2.0 or the website, please join us on the Capistrano mailing list and make your voice heard!

While Rails Edge continues to move forward at a rapid clip, we’ve still had the time to make sure that Rails 1.2.x stays in the game. This release irons out the few wrinkles there was between Ruby 1.8.6 and Rails 1.2.2. So now you can enjoy the latest Ruby with the latest Rails.

Besides the 1.8.6 compatibility, we’ve included a few minor fixes. Nothing major. This should be a drop-in replacement for Rails 1.2.2.

As always, you can upgrade with gems or use the latest svn tag (rel_1-2-3). Enjoy!

Here it is, another Capistrano release, and less than a month since the last one! Miracles truly never cease.

Capistrano, for those embarrassingly late to the party, is a utility for executing commands in parallel on multiple remote servers. It is useful for lots of things, including automating deployment of Rails applications.

Version 1.4.1, available just as soon as the mirrors get updated, is a pretty minor update, but has one new feature:

You can now pass :env to ‘run’ (and friends), in order to specify environment variables that should be set for that command. For example:

run “some_batch_thang.rb”, :env => { “DEBUG” => “1” }

There is also one deprecation: if you are using UPPERCASE variables in your Capistrano recipes, you’ll being seeing warnings now. Support for variables that start with uppercase letters will be removed altogether in Capistrano 2.0. If you want uppercase identifiers, you should use Ruby constants.

The two fixes in this release:

Actor#get will not close the SFTP channel when it finishes. This makes it possible to do multiple SFTP gets and puts in a single session.

The subversion adapter now passes the “no-auth-cache” option, so that if you configure an explicit subversion username for deployment other than your dev username, those deployment auth tokens won’t clobber your development tokens.

So, go get it, “gem install capistrano.” Or download it directly from RubyForge. And at the risk of promising too much, too early: I expect this to be the last 1.x release of Capistrano, barring any critical problems that may arise with 1.4.1. Come on, cap2!

You’ve all noticed the excruciating Rails svn updates and Trac molasses in the last couple of weeks. Following the release of Rails 1.2 we thoroughly overwhelmed our development server, no small feat for a hefty dual Xeon. Congratulations, all, for your hearty Rails appetite! Your sustained Mbps say more than words possibly could.

Our friends at TextDrive have stepped up once again to keep Rails development running smoothly and your production apps deploying predictably. Please give a warm welcome to our new development cluster, a load-balanced crew of SunFires and Thumpers hosting Trac at dev.rubyonrails.org and Subversion at svn.rubyonrails.org.

Subversion will remain available at the old dev URL so you needn’t touch your live apps. Feel free to migrate to the new URL at your own speed.

It’s time for another minor update to Rails 1.2. This was primarily prompted by a change in the API for SQLite between version 3.3.7 and 3.3.8+, which left the Rails database adapter for dead by the road side. But with this release and Jamis Buck’s sqlite3-ruby gem at version 1.2.1, we’re back in business on all versions of SQLite3.

Second, we’re now depending on RubyGems 0.9.0 and above. This will fix the deprecation messages for require_gem (the new method is just gem) and will restore rake rails:freeze:gems to working order. So be sure to update to the latest RubyGems before installing. That’s done with “gem update —system”.

Finally, we’ve decided to throw in a few goodies along with the fixes described above and the rest of the bug reparations in this release. Singular resources, for example, allow you to model singleton resources within the scope of the domain. The common example is user.application.com/account. That’s now modeled with:

Note that the controller is also singular, not plural as is usually the case when using map.resources.

We’ve also brought over the enhancement to :conditions in Active Record that’ll allow you to pass in ranges and get them automatically converted to BETWEEN statements. Like:

Student.find(:all, :conditions => { :grade => 9..12 })

…which then becomes:

“SELECT * FROM students WHERE grade BETWEEN 9 AND 12”

This is a recommended upgrade for everyone running 1.2.x (and a reminder that if you’re not yet on Rails 1.2.x, you won’t be getting bug fixes automatically and have to backport them yourself). It’s a drop-in replacement requiring no changes to applications running 1.2.×.

Capistrano is a utility for executing commands in parallel on multiple machines, such as for automating the deployment of applications. Version 1.4.0 is now available.

To install:

gem install capistrano

Version 1.4.0 fixes a few bugs, and adds a few features. The new features:

A “capture” helper has been added, to make it easy to capture the stdout of a remote command and return it as a string:

result = capture(“uptime”)

A “get” helper has been added, to mirror the “put” command, letting you easily download files from a remote server to the local host. It will only download from the first server that matches the criteria for the current task. You must have Net::SFTP installed (gem install net-sftp) in order to use the “get” helper.

get “#{current_path}/log/production.log”, “logs/production.log”

Support for a system-wide config file has been added. If a file exists in “/etc/capistrano.conf”, it will be loaded immediately after the standard recipe file is loaded, and immediately before any user-specific configuration.

The fixed bugs:

There used to be issues with cap hanging when running multiple capistrano instances at the same time when using gateways. This has been fixed.

The permissions tweaking in the standard recipe has been refactored into a separate task (set_permissions), which you can override if you are on a host that won’t let you set group-writable permissions.

The setup task now uses umask so that intermediate directories are created with the proper permissions.

Make sure the standard recipe loads first, so that .caprc and friends can oerride what it defines.

cold_deploy now calls update instead of deploy, to avoid invoking the restart task.

The ‘touch’ command in update_code now sets TZ to UTC for the duration of that command, so that asset timestamps are set correctly.

An off-by-one bug in the width computation for show_tasks has been fixed.

Minor deprecations:

The c/-caprc switch has been removed, since the new load order (standard, system, user, application) makes it meaningless.

Thanks to Mark Imbriaco, Neil Wilson, Bojan Mihelac, Joshua Wehner, and Mike Bailey for their contributions to this release.

Since we’re all celebrating new releases, it seems only fair to point out that Haml, an alternative markup format to Rails’ RHTML templates, has reached the lofty version of 1.0. It even comes with a plugin for seamless integration with Rails applications, so you really have no excuse not to give it a try. If you’re looking for an alternative to RHTML, Haml may just be you. Check it out!

Prototype 1.5 shipped together with Rails 1.2 today. But that’s not all that’s been happening at the JavaScript sugar mill. Today also marks the official unveiling of prototypejs.org. A brand new site dedicated to promoting and teaching Prototype. It comes complete with API documentation, a blog, and a guide on how to contribute. Congratulations to Sam, Justin, and the rest of the team behind the site.

Get out your party balloons and funny hats because we’re there, baby. Yes, sire, Rails 1.2 is finally available in all it’s glory. It took a little longer than we initially anticipated to get everything lined up (and even then we had a tiny snag that bumped us straight from 1.2.0 to 1.2.1 before this announcement even had time to be written).

So hopefully it’s been worth the wait. Who am I kidding. Of course it’s been worth the wait. We got the RESTful flavor with new encouragement for resource-oriented architectures. We’re taking mime types, HTTP status codes, and multiple representations of the same resource serious. And of course there’s the international pizzazz of multibyte-safe UTF-8 wrangling.

That’s just some of the headliner features. On top of that, there’s an absolutely staggering amount of polish being dished out. The CHANGELOG for Action Pack alone contains some two hundred entries. Active Record has another 170-something on top of that.

All possible due to the amazing work of our wonderful and glorious community. People from all over the world doing their bit, however big or small, to increase the diameter of your smile. That’s love, people.

As always, you get a hold of the latest and greatest through gems:

gem install rails —include-dependencies

…or if you prefer to freeze it straight up, you can:

rake rails:freeze:edge TAG=rel_1-2-1

If you go with the gems, remember to change your version binding in config/environment.rb. Otherwise, you’ll still be tied to whatever old version you were using before.

Do note, though, that this is a massive upgrade. A few major components of Rails were left for scraps and entirely rewritten (routing and auto-loading included). We’ve tried our very best to remain backwards compatible. We’ve run multiple release candidate sessions to everyone help achieve that goal.

But it may not be perfect — heck, what is — so you’d be best advised to give your application a full and thorough work-out before contemplating a deployment. But of course, you’ve been such a good little tester bee that all what is needed is a single “rake” to see if everything passes, right?

How to get started learning all about Rails 1.2

With the fanfare out of the way, I point your attention to a rerun of the RC1 release notes on the new features. This rerun only contains the highlights, though. Real fans will want to peruse the CHANGELOGs themselves from the API.

For everyone else, there’s of course also the much easier path of just picking up the second edition of Agile Web Development with Rails. This edition was written to be spot on with 1.2 and contains a lot more elaborate guidance than you’ll find in the CHANGELOGs.

So it’s no wonder that the 2nd edition sold out the 15,000 copies of the first print run in a mere three weeks. Rest assured, though, the second run should already be available in stores. And for instant gratification, nothing beats picking up the PDF+Book combo off the Pragmatic book site.

REST and Resources

REST, and general HTTP appreciation, is the star of Rails 1.2. The bulk of these features were originally introduced to the general public in my RailsConf keynote on the subject. Give that a play to get into the mindset of why REST matters for Rails.

Then start thinking about how your application could become more RESTful. How you too can transform that 15-action controller into 2-3 new controllers each embracing a single resource with CRUDing love. This is where the biggest benefit is hidden: A clear approach to controller-design that’ll reduce complexity for the implementer and result in an application that behaves as a much better citizen on the general web.

To help the transition along, we have a scaffold generator that’ll create a stub CRUD interface, just like the original scaffolder, but in a RESTful manner. You can try it out with “script/generate scaffold_resource”. Left with no arguments like that, you get a brief introduction to how it works and what’ll create.

The only real API element that binds all this together is the new map.resources, which is used instead of map.connect to wire a resource-based controller for HTTP verb love. Then, once you have a resource-loving controller, you can link with our verb-emulation link link_to "Destroy", post_url(post), :method => :delete. Again, running the resource scaffolder will give you a feel for how it all works.

Formats and respond_to

While respond_to has been with us since Rails 1.1, we’ve added a small tweak in 1.2 that ends up making a big difference for immediate usefulness of the feature. That is the magic of :format. All new applications will have one additional default route: map.connect ':controller/:action/:id.:format'. With this route installed, imagine the following example:

Using the Accept header to accomplish this is no longer necessary. That makes everything a lot easier. You can explore your API in the browser just by adding .xml to an URL. You don’t need a before_filter to look for clues of a newsreader, just use .rss. And all of them automatically works with page and action caching.

Of course, this format-goodness plays extra well together with map.resources, which automatically makes sure everything Just Works. The resource-scaffold generator even includes an example for this using format.xml, so /posts/5.xml is automatically wired up. Very nifty!

Multibyte

Unicode ahoy! While Rails has always been able to store and display unicode with no beef, it’s been a little more complicated to truncate, reverse, or get the exact length of a UTF-8 string. You needed to fool around with KCODE yourself and while plenty of people made it work, it wasn’t as plug’n’play easy as you could have hoped (or perhaps even expected).

So since Ruby won’t be multibyte-aware until this time next year, Rails 1.2 introduces ActiveSupport::Multibyte for working with Unicode strings. Call the chars method on your string to start working with characters instead of bytes.

Imagine the string ‘€2.99’. If we manipulate it at a byte-level, it’s easy to get broken dreams:

‘€2.99’[0,1] # => “\342”
‘€2.99’[0,2] # => “?”
‘€2.99’[0,3] # => “€”

The € character takes three bytes. So not only can’t you easily byte-manipulate it, but String#first and TextHelper#truncate used to choke too. In the old days, this would happen:

‘€2.99’.first # => ‘\342’
truncate(‘€2.99’, 2) # => ‘?’

With Rails 1.2, you of course get:

‘€2.99’.first # => ‘€’
truncate(‘€2.99’, 2) # => ‘€2’

TextHelper#truncate/excerpt and String#at/from/to/first/last automatically does the .chars conversion, but if when you need to manipulate or display length yourself, be sure to call .chars. Like:

You’ve written <%= @post.body.chars.length %> characters.

With Rails 1.2, we’re assuming that you want to play well with unicode out the gates. The default charset for action renderings is therefore also UTF-8 (you can set another with ActionController::Base.default_charset=(encoding)). KCODE is automatically set to UTF-8 as well.

Routes

Action Pack has an all new implementation of Routes that’s both faster and more secure, but it’s also a little stricter. Semicolons and periods are separators, so a /download/:file route which used to match /download/history.txt doesn’t work any more. Use :requirements => { :file => /.*/ } to match the period.

Auto-loading

We’ve fixed a bug that allowed libraries from Ruby’s standard library to be auto-loaded on reference. Before, if you merely reference the Pathname constant, we’d autoload pathname.rb. No more, you’ll need to manually require 'pathname' now.

We’ve also improved the handling of module loading, which means that a reference for Accounting::Subscription will look for app/models/accounting/subscription.rb. At the same time, that means that merely referencing Subscription will not look for subscription.rb in any subdir of app/models. Only app/models/subscription.rb will be tried. If you for some reason depended on this, you can still get it back by adding app/models/accounting to config.load_paths in config/environment.rb.

Prototype

To better comply with the HTML spec, Prototype’s Ajax-based forms no longer serialize disabled form elements. Update your code if you rely on disabled field submission.

For consistency Prototype’s Element and Field methods no longer take an arbitrary number of arguments. This means you need to update your code if you use Element.toggle, Element.show, Element.hide, Field.clear, and Field.present in hand-written JavaScript (the Prototype helpers have been updated to automatically generate the correct thing).

// if you have code that looks like this
Element.show('page', 'sidebar', 'content');
// you need to replace it with code like this
['page', 'sidebar', 'content'].each(Element.show);

Action Mailer

All emails are MIME version 1.0 by default, so you’ll have to update your mailer unit tests: @expected.mime_version = '1.0'

Deprecation

Since Rails 1.0 we’ve kept a stable, backward-compatible API, so your apps can move to new releases without much work. Some of that API now feels like our freshman 15 so we’re going on a diet to trim the fat. Rails 1.2 deprecates a handful of features which now have superior alternatives or are better suited as plugins.

Deprecation isn’t a threat, it’s a promise! These features will be entirely gone in Rails 2.0. You can keep using them in 1.2, but you’ll get a wag of the finger every time: look for unsightly deprecation warnings in your test results and in your log files.

Treat your 1.0-era code to some modern style. To get started, just run your tests and tend to the warnings.

I’ve been remiss in announcing recent Capistrano releases, so I’m making up for lost time now. Capistrano 1.3.1 is now available!

Capistrano, for those of you that are late to the game, is a utility for executing commands in parallel on multiple remote machines. It comes with support for vastly simplifying the deployment process of Rails applications, but can be customized to work with virtually any environment.

Since 1.2.0, the following enhancements and changes have been made:

You can encode the username and port for a host in the host string. Does one machine require a different user than another? A non-standard port for SSH access? It’s as simple as:

role :app, "app1.host.com"
role :web, "webuser@web1.host.com"
role :db, "db1.host.com:1234"
role :file, "fileuser@file1.host.com:1234"

You can pass an :as option to sudo, to specify which user a command should be run as:

sudo "spinner", :as => "app"

If you define a “.caprc” file in your home directory, Capistrano will automatically load that file on every invocation. (It has the same format as any other Capistrano recipe file.)

Assets in the images, javascripts, and stylesheets directories are now touched after updating the code, to ensure that Rails’ asset timestamping feature works correctly.

Make sure new setups and checkouts are group-writable.

Do not run the cleanup task on servers marked “no_release”.

Rake integration is now deprecated. You should be invoking ‘cap’ directly. A future release will remove rake integration altogether.

Feel free to read the changelog several other fixes and tweaks. It might be a few hours before the 1.3.1 gem reaches all the mirrors, but when it gets there, a simple “gem install capistrano” ought to do the trick!

This is it. We’re a mere two shakes of a lamb’s tail from releasing the final version of Rails 1.2. But before we light the fireworks and pop the champagne, we’ll just do one itsy, bitsy, tiny test run. Like wearing protection glasses in downtown Copenhagen on New Year’s. You know, just for precautions.

So please do give it a good run. We’re looking for STOPTHEBOAT and HOLDTHEPRESSES kind of issues for this one. Nothing else will stop it (but please do report every thing you find any way).

And how many blogs have you visited that say “Last updated 60 days ago”? Years and months have been added to distance_of_time_in_words, so you’ll see “2 months ago” or maybe even “5 years ago” now.

Controllers

Uncaught exceptions raised anywhere in your application will cause RAILS_ROOT/public/500.html to be read and shown instead of just the static “Application error (Rails).” So make it look nice if you aren’t using it already!

There is a new head(options = {}) method for responses that have no body.

You can declare specific file extensions exempt from layouts. Bring on the CSS, PDF, and graphic generating plugins!

ActionController::Base.exempt_from_layout 'rpdf'

RESTful resources automatically get a params[:format] option that can force a content type. If :format is specified and matches a declared extension, that mime type will be used in preference to the “Accept” header. This means you can link to the same action from different extensions and use that fact to determine output (cheat sheet).

Associations

Allow :uniq => true with has_many :through associations. This is equivalent to doing a SELECT DISTINCT in SQL, but it is done in Ruby code instead.

Add records to has_many :through using <<, push, and concat by creating the join model record. Raise if base or associate are new records since both ids are required to create the association. #build raises an error since you can't associate an unsaved record. #create! takes an attributes hash and creates both the associated record and its join model record in a transaction.

It’s been almost eight months since the last major release of Rails introduced RJS, respond_to, eager loading, and much more. It’s about time we introduced the latest batch of big ideas we’ve been polishing in the interim.

Since this is a major new release and we’ve gotten so much incredible uptake even since 1.1, we’re feeling the need to certify that things work as well as they can out the gates. Thus, this release candidate to fret out any regressions or major issues with the new features.

Update:Josh Susser has more on what this means for developers, and how best to go about submitting bug reports for the new release.

What’s New

But first, allow me to give you a short rundown of what you should be excited about. While these new features may not appear to have the immediate glitz and glamour the likes of RJS, they still represent a big fundamental shift in how a lot of Rails applications will be created from this day forth.

REST and Resources

REST, and general HTTP appreciation, is the star of Rails 1.2. The bulk of these features were originally introduced to the general public in my RailsConf keynote on the subject. Give that a play to get into the mindset of why REST matters for Rails.

Then start thinking about how your application could become more RESTful. How you too can transform that 15-action controller into 2-3 new controllers each embracing a single resource with CRUDing love. This is where the biggest benefit is hidden: A clear approach to controller-design that’ll reduce complexity for the implementer and result in an application that behaves as a much better citizen on the general web.

To help the transition along, we have a scaffold generator that’ll create a stub CRUD interface, just like the original scaffolder, but in a RESTful manner. You can try it out with “script/generate scaffold_resource”. Left with no arguments like that, you get a brief introduction to how it works and what’ll create.

The only real API element that binds all this together is the new map.resources, which is used instead of map.connect to wire a resource-based controller for HTTP verb love. Then, once you have a resource-loving controller, you can link with our verb-emulation link link_to "Destroy", post_url(post), :method => :delete. Again, running the resource scaffolder will give you a feel for how it all works.

Formats and respond_to

While respond_to has been with us since Rails 1.1, we’ve added a small tweak in 1.2 that ends up making a big difference for immediate usefulness of the feature. That is the magic of :format. All new applications will have one additional default route: map.connect ':controller/:action/:id.:format'. With this route installed, imagine the following example:

Using the Accept header to accomplish this is no longer necessary. That makes everything a lot easier. You can explore your API in the browser just by adding .xml to an URL. You don’t need a before_filter to look for clues of a newsreader, just use .rss. And all of them automatically works with page and action caching.

Of course, this format-goodness plays extra well together with map.resources, which automatically makes sure everything Just Works. The resource-scaffold generator even includes an example for this using format.xml, so /posts/5.xml is automatically wired up. Very nifty!

Multibyte

Unicode ahoy! While Rails has always been able to store and display unicode with no beef, it’s been a little more complicated to truncate, reverse, or get the exact length of a UTF-8 string. You needed to fool around with KCODE yourself and while plenty of people made it work, it wasn’t as plug’n’play easy as you could have hoped (or perhaps even expected).

So since Ruby won’t be multibyte-aware until this time next year, Rails 1.2 introduces ActiveSupport::Multibyte for working with Unicode strings. Call the chars method on your string to start working with characters instead of bytes.

Imagine the string ‘€2.99’. If we manipulate it at a byte-level, it’s easy to get broken dreams:

‘€2.99’[0,1] # => “\342”
‘€2.99’[0,2] # => “?”
‘€2.99’[0,3] # => “€”

The € character takes three bytes. So not only can’t you easily byte-manipulate it, but String#first and TextHelper#truncate used to choke too. In the old days, this would happen:

‘€2.99’.first # => ‘\342’
truncate(‘€2.99’, 2) # => ‘?’

With Rails 1.2, you of course get:

‘€2.99’.first # => ‘€’
truncate(‘€2.99’, 2) # => ‘€2’

TextHelper#truncate/excerpt and String#at/from/to/first/last automatically does the .chars conversion, but if when you need to manipulate or display length yourself, be sure to call .chars. Like:

You’ve written <%= @post.body.chars.length %> characters.

With Rails 1.2, we’re assuming that you want to play well with unicode out the gates. The default charset for action renderings is therefore also UTF-8 (you can set another with ActionController::Base.default_charset=(encoding)). KCODE is automatically set to UTF-8 as well.

Gotchas

While we’ve tried our best to remain as backwards compatible with 1.1.6 as possible, there are a few minor edge cases that will need some rework if you used to do things a certain way.

Routes

Action Pack has an all new implementation of Routes that’s both faster and more secure, but it’s also a little stricter. Semicolons and periods are separators, so a /download/:file route which used to match /download/history.txt doesn’t work any more. Use :requirements => { :file => /.*/ } to match the period.

Auto-loading

We’ve fixed a bug that allowed libraries from Ruby’s standard library to be auto-loaded on reference. Before, if you merely reference the Pathname constant, we’d autoload pathname.rb. No more, you’ll need to manually require 'pathname' now.

We’ve also improved the handling of module loading, which means that a reference for Accounting::Subscription will look for app/models/accounting/subscription.rb. At the same time, that means that merely referencing Subscription will not look for subscription.rb in any subdir of app/models. Only app/models/subscription.rb will be tried. If you for some reason depended on this, you can still get it back by adding app/models/accounting to config.load_paths in config/environment.rb.

Prototype

To better comply with the HTML spec, Prototype’s Ajax-based forms no longer serialize disabled form elements. Update your code if you rely on disabled field submission.

For consistency Prototype’s Element and Field methods no longer take an arbitrary number of arguments. This means you need to update your code if you use Element.toggle, Element.show, Element.hide, Field.clear, and Field.present in hand-written JavaScript (the Prototype helpers have been updated to automatically generate the correct thing).

// if you have code that looks like this
Element.show('page', 'sidebar', 'content');
// you need to replace it with code like this
['page', 'sidebar', 'content'].each(Element.show);

Action Mailer

All emails are MIME version 1.0 by default, so you’ll have to update your mailer unit tests: @expected.mime_version = '1.0'

Deprecation

Since Rails 1.0 we’ve kept a stable, backward-compatible API, so your apps can move to new releases without much work. Some of that API now feels like our freshman 15 so we’re going on a diet to trim the fat. Rails 1.2 deprecates a handful of features which now have superior alternatives or are better suited as plugins.

Deprecation isn’t a threat, it’s a promise! These features will be entirely gone in Rails 2.0. You can keep using them in 1.2, but you’ll get a wag of the finger every time: look for unsightly deprecation warnings in your test results and in your log files.

Treat your 1.0-era code to some modern style. To get started, just run your tests and tend to the warnings.

Installing

The release candidate gems live in the Rails gem repository. You install them like this:

Note that it’ll say something like “Successfully installed rails-1.1.6.5618”. That’s correct as we won’t use the final version numbers until the official release.

You can also grab it straight from Subversion with http://dev.rubyonrails.org/svn/rails/tags/rel_1-2-0_RC1.

Submitting regression bugs

There you have it. Those are the major changes and as always, you can get the full, nitty-gritty scoop in the CHANGELOGs. Over the last eight months, we’ve made literaly hundreds of improvements. It’s well worth traversing the CHANGELOGs for goodies. Ryan’s Scraps is doing a good job annotating the changes as well.

But with the release of any new piece of software, a number of things which used to work, will work no longer.

While the intention with Rails 1.2 is to provide seamless backwards compatibility, we’re only human, and chances are a few things have snuck through. So if you’re trying out the 1.2 release candidate, and find a bug, be sure to report it to us. There are a few steps you should follow to help us fix your bug during the release canididate cycle.

When adding your bug report, be sure to put ‘1.2regression’ in the keywords field. Bugs with this keyword show up in a trac report, if you’re looking for a place to help out, start there.

If at all possible, please include a failing unit test with your bug report. This makes our life significantly easier, and helps others verify that you’ve found a genuine case.

A new release of Capistrano is nearly upon us! Before I unleash it upon the world, though, I’d like to have a few brave souls put it through its paces, so I’m doing a brief run of it as a pre-release. You can grab it from the Rails beta gem server:

gem install -s http://gems.rubyonrails.com capistrano

There are a lot of changes in this release, most of them minor or cosmetic. However, there are some changes that may bite you, too.

The most significant change that may affect you has to do with the roles used for the setup, update_code, rollback_code, and symlink tasks. These tasks have changed such that they now deploy to all defined servers. That’s right, if you’ve got a server associated with any role, those tasks will deploy to that server. However, a server can explicitly opt out of being part of release deployment by setting :no_release => true in its role definition:

role :file, "file-server.somewhere.example",
:no_release => true

Take note of that! If you have any servers using non-standard roles (any role besides web, app, or db), you need to explicitly add :no_release => true in their role definitions, or your next deploy will target those servers, too.

Other significant changes that may or may not tickle you:

The -r/--recipe command line option is deprecated. You should use -f/--file instead.

Matthew Elder has contributed (and agreed to maintain) a module for the Mercurial SCM.

If you have sudo in a non-standard location, you can specify the path to sudo via the :sudo variable

Added :svn_passphrase so you can use keys with passphrases

Fixed missing default for :local in the CVS module

Subversion SCM accepts HTTPS certificates now

Work with pid-based setups (new spawner/reaper)

Added update task

Added :except on task declarations (as the opposite of :only)

Override the hosts to be used for a task via the HOSTS environment variable

Override the roles that will be used for a task via the ROLES environment variable

Added :hosts option on task declarations for defining tasks that work only on specific machines (rather than by role)

Don’t require a capfile (this allows you to use capistrano to operate on arbitrary hosts, all from the command line)

Various other changes have been made as well—you can look at the CHANGELOG for a complete list.

The cat is out of the bag, so here’s the full disclosure edition of the current security vulnerability. With Rails 1.1.0 through 1.1.5 (minus the short-lived 1.1.3), you can trigger the evaluation of Ruby code through the URL because of a bug in the routing code of Rails. This means that you can essentially take down a Rails process by starting something like /script/profiler, as the code will run for a long time and that process will be hung while it happens. Other URLs can even cause data loss.

We’ve backported a fix to all the affected versions for those of you that can’t update. You’ll have to apply the diff for your version:

These patches (and 1.1.6) will break applications using the 3rd party engines idea. So if you can’t upgrade because of dependencies to those, you can also add the following URL blocking while engines are being updated. Here’s how to do it with mod_rewrite under Apache:

Unfortunately, the 1.1.5 update from yesterday only partly closed the hole (getting rid of the worst data loss trigger). After learning more about the extent of the problem, we’ve now put together a 1.1.6 release that completely closes all elements of the hole (using the same technique as the backports above).

So if you upgraded to 1.1.5 yesterday, you need to upgrade again. The approach stays the same, but since the Rubyforge gem server can be very slow at distributing gem updates, you should grab this fix straight from the Rails server:

If you’re running of trunk (also known as edge) using revision 4394 or later, you’re not affected by all this in any form.

We’ll follow up with more information as it becomes available. Needless to say, this is all the Rails core team is working on right now and we’ve recruited a whole band of testers to help us play this out. We’ll make sure to evaluate all the feedback that’s been coming in and develop some scar tissue a policy for dealing with security issues in the future. Thanks for your continued understanding.

We’ve also started #rails-security on Freenet for people with IRC available to get and share more information.

UPDATE: If you’re floating on gems (don’t have vendor/rails), then make sure you update RAILS_GEM_VERSION in your config/environment.rb. Otherwise you’ll still be bound to that earlier version of Rails even as you install the new gems.

UPDATE 2: Rails 1.1.6 is now available on the official gem server, so you no longer need to add the —source http://gems.rubyonrails.org parameter.

We’re still hard at work on Rails 1.2, which features all the new dandy REST stuff and more, but a serious security concern has come to our attention that needed to be addressed sooner than the release of 1.2 would allow. So here’s Rails 1.1.5!

This is a MANDATORY upgrade for anyone not running on a very recent edge (which isn’t affected by this). If you have a public Rails site, you MUST upgrade to Rails 1.1.5. The security issue is severe and you do not want to be caught unpatched.

The issue is in fact of such a criticality that we’re not going to dig into the specifics. No need to arm would-be assalients.

So upgrade today, not tomorrow. We’ve made sure that Rails 1.1.5 is fully drop-in compatible with 1.1.4. It only includes a handful of bug fixes and no new features.

For the third time: This is not like “sure, I should be flossing my teeth”. This is “yes, I will wear my helmet as I try to go 100mph on a motorcycle through downtown in rush hour”. It’s not a suggestion, it’s a prescription. So get to it!

As always, the trick is to do “gem install rails” and then either changing config/environment.rb, if you’re bound to gems, or do “rake rails:freeze:gems” if you’re freezing gems in vendor.

UPDATE: This problem affects 0.13, 0.14, 1.0, and 1.1.×. So here’s a happy opportunity to upgrade if you still haven’t.

UPDATE 2: We’ve fixed the zlib buffer problems for people on Windows. Redownload the gem and everything should be dandy.

UPDATE 3: Regarding security through obscurity, we’ll release the full details of this issue once everyone has had a fair chance to upgrade their system. Source transparency is of little comfort if you just had your system compromised before you got a chance to apply the patch.

UPDATE 4: This problem does not affect Rails 1.0 or earlier. The only versions affected are 1.1.0, 1.1.1, 1.1.2, and 1.1.4. See security update for details.

The security fix from Rails 1.1.3 might have closed the hole, but it also caused breakage for people with controllers in modules. We’ve fixed that now, so Rails 1.1.4 should work for any application that also ran under 1.1.2. We apologize for the problem with 1.1.3 and encourage everyone running 1.1.x to upgrade as soon as possible to this release.

Note: Edge Rails was never affected by this security issue as it includes a rewritten routes module. So if you’re running on the latest edge, you don’t need to worry about upgrading.

We’ve found and fixed a security issue with routing that could cause excess CPU usage in Rails processes when triggered by certain URLs. We strongly encourage anyone running 1.1.x to upgrade to the latest version. It’s fully backwards compatible and should serve as a small drop-in fix.

If you’re running the latest Edge Rails, though, there’s no need to update. We’ve rewritten the routes functionality on edge and the new version doesn’t have this problem.

To upgrade, you as always can just do: gem install rails --include-dependencies

Note: This release doesn’t include any of the new CRUD/resource-based features. All of the new features we’ve been working on over the last couple of months will become available in 1.2.0, which is scheduled for “soonish”. This 1.1.3 release is purely to address the security issue and another few minor fixes that were available on the STABLE branch as well.

From almost the day we checked rjs into the repository, Cody was quickly singling himself out as an expert. When he found out they weren’t going to make the 1.0 release, he made an rjs plugin available for those staying back at 1.0. Before we had extensive documentation, he was doing the dirty work, putting together various tutorials and explanations. Many of you likely learned about rjs from Cody. And now, many more of you likely will too.

Jaded Pixel wisely brought him onto their team. He’s applied his rjs skills to great effect on Shopify.

As a reviewer of RJS Templates for Rails, I can attest to it being comprehensive and up to date. The book provides a tutorial style guide to using rjs then at the end there is a full reference. Most impressively, Cody is a solid technical writer. I’m quite sure this is his first book yet it reads like it was written by someone who’s been doing this for years. I hope it’s not his last.

Bounty Source provides the Open Source community with free hosting and tools including a task manager, a CMS, and a Subversion Code Repository. They’ve been gracious enough to release the Subversion Browser as a Rails plugin.

I’ve posted a technique on Rails Weenie on using your application’s authentication scheme on the plugin, so that your secret sauce is not available to the whole world.

Have you ever wanted to write Rails routes using a URL's subdomain? What about routing based on whether a request was HTTP vs HTTPS? Well, now you can. Recently Dan Webb released his "Request Routing Plugin":http://svn.vivabit.net/external/rubylibs/request_routing/README for public use. This plugin lets you create routing rules that use a whole slew of new properties: domain, subdomain, method, port, remote_ip, content_type, accepts, request_uri, and protocol.

It’s nice that ActiveRecord logs the queries that are performed when your actions are executed, since it makes it easy to see when you have serious inefficiencies in your application. The next question, though, is always, “OK, so where are those being run from?

Dave Thomas has just announced that the first release-candidate of Rails Recipes is now available. What that means is that the book is essentially in its finished form. It’s had a great beta run, with a lot of praise and good feedback. Now that it’s been put through its passes, it’s pretty much ready for primetime, sporting 70 solutions to your real world programming challenges. If you’ve been holding off, now is a great time to get in on what is shaping up to be the de facto companion to Agile Web Development with Rails.

The new gem version dependency system from Rails 1.1.1 needed a few tweaks to work properly and to stop throwing meaningless warnings. This tiny release makes up for that. To install:

gem install rails

rake rails:update:configs (to get the latest config/boot.rb)

This release also signals our new commitment to do more tiny releases from the stable branch, which only gets bug fixes. So it will not be uncommon to see bi-weekly tiny releases in the 1.1.x series while we continue to add features to the forthcoming 1.2.0.

Rails 1.1 was a big upgrade with a lot of new features and we’ve been working hard since its release to polish off the kinks revealed after it was deployed to the masses. Rails 1.1.1 contains fixes for things like Prototype memory leaks in IE 6, Oracle adapter runnings, and a number of compatibility tweaks to make most older applications work.

This release still doesn’t work with Typo, though. And it won’t. Instead you must freeze Rails 1.0 to vendor/rails if you run Typo 2.6.0 while we await the new release from the Typo team that will be fully 1.1 compatible. Read more about Typo and how to freeze Rails.

This is the release we recommend that hosting companies upgrade to. If you still haven’t frozen your application and it for some reason doesn’t work with Rails 1.1.1, don’t run crying to them. We screwed up in the release notes of the last release by not telling people that Typo would break, but now that this information is spread far and wide, it’ll rest on your shoulders to make sure you’re frozen and stay cool.

If you still haven’t upgraded to Rails 1.1, checkout the original announcement for a run-through of all the features.

One of the casualties of the 1.1 release was the experimental upload progress helper. Unfortunately it didn’t work on all the platforms we support and it was a source of numerous bug reports. After talking with Sean, we decided to remove it from rails’ core.

For those of you who were using it, the code was extracted to a rails plugin. To install it just run the following command and everything will be back where you need it.

The biggest upgrade in Rails history has finally arrived. Rails 1.1 boasts more than 500 fixes, tweaks, and features from more than 100 contributors. Most of the updates just make everyday life a little smoother, a little rounder, and a little more joyful.

But of course we also have an impressive line of blockbuster features that will make you an even happier programmer. Especially if you’re into Ajax, web services, and strong domain models — and who isn’t these funky days?

The star of our one-one show is RJS: JavaScript written in Ruby. It’s the perfect antidote for your JavaScript blues. The way to get all Ajaxified without leaving the comfort of your beloved Ruby. It’s the brainchild of JavaScript and Ruby mastermind Sam Stephenson and an ode to the dynamic nature of Ruby.

And that’s just a tiny taste of what RJS is capable of. It takes the Ajax on Rails experience far above and beyond the great support we already had. Bringing us even closer to the goal of “as easy as not to”. Read more about RJS in the docs or in Cody Fauser’s tutorial about element and collection proxies and his introduction to RJS (it shouldn’t surprise you that Cody is writing about book about RJS for O’Reilly).

But its not just the view we’re giving some tender love, oh no. Active Record has been blessed with bottomless eager loading, polymorphic associations, join models, to_xml, calculations, and database adapters for Sybase and OpenBase. It’s a huge upgrade and made possible through the fantastic work of Rick Olson (who was recently accepted into Rails Core, not a minute too soon!) and Anna Chan. Let’s dig into three of the top features:

Bottomless eager loading gives you the power of pulling back a multi-level object graph in a single JOIN-powered SQL query. Example:

Now let’s have a look at the new respond_to feature of Action Controller that makes it much easier to launch your application with both Ajax, non-Ajax, and API access through the same actions. By inspecting the Accept header, we can do clever stuff like:

Speaking of Jamis, he also added the third layer of testing to Rails: Integration tests. They allow you to faithfully simulate users accessing multiple controllers and even gives you the power to simulate multiple concurrent users. It can really give you a whole new level of confidence in your application. The 37signals team used it heavily in Campfire from where it was later extracted into Rails. See Jamis’ great guide to integration testing for more.

These highlighted features are just the tip of the iceberg. Scott Raymond has done a great job trying to keep a tab on all the changes, see his What new in Rails 1.1 for a more complete, if brief, walk-through of all the goodies. And as always, the changelogs has the complete step-by-step story for those of you who desire to know it all.

And as mentioned before, Chad Fowler’s excellent Rails Recipes has in-depth howtos on a lot of the new features. If you desire some packaged documentation, this is the book to pick up.

Upgrading from 1.0

So with such a massive update, upgrading is going to be hell, right? Wrong! We’ve gone to painstaking lengths to ensure that upgrading from 1.0 will be as easy as pie. Here goes the steps:

Update to Rails 1.1:gem install rails --include-dependencies

Update JavaScripts for RJS:rake rails:update

That’s pretty much it! If you’re seeing any nastiness after upgrading, it’s most likely due to a plugin that’s incompatible with 1.1. See if the author hasn’t updated it and otherwise force him to do so.

If you’re on Ruby 1.8.2 with Windows, though, you’ll want to upgrade to the 1.8.4 (or the script/console will fail). And even if you’re on another platform, it’s a good idea to upgrade to Ruby 1.8.4. We still support 1.8.2, but might not in the next major release. So may as well get the upgrading with over with now.

It’s been roughly three months since the release of the big one-oh. That’s obviously an eternity in Rails time, so its about high time we’re getting ready for the release for 1.1. And boy, is this an exciting upgrade!

I do believe this is the biggest upgrade to Rails we’ve ever done. We have recorded about 500 fixes, tweaks, and new features in the changelogs. That’s a lot and that’s just counting major new features like RJS as one.

So with all these goodies, we want to make sure we launch without any obvious blunders or backwards compatibility breaking changes. This is why we’re doing a release candidate and why we need your help to test it.

Rails 1.1 is supposed to be just fully backwards compatible with 1.0, but we did change just a couple of defaults, see CHANGEDDEFAULT notes in the changelogs. That means we want to test Rails 1.1 with as many 1.0 applications as possible.

Or you can just install the new Rake gem (Rails 1.1 depends on Rake 0.7) and then call rake freeze_edge. That’ll pull the latest Rails down from the Subversion repository and bind just that one application to it.

Or you can set svn:externals on vendor/ to be against http://dev.rubyonrails.org/svn/rails/tags/rel_1-1-0_RC1, if you want to pull it in through Subversion automatically.

Lots of options, no excuses. We really need your help to make sure the final release is as solid as Rails 1.0 was. And so we don’t need 1.1.1 two days later.

Once you have the latest Rails installed, you can do rake rails:update to get the latest scripts and the latest version of Prototype and script.aculo.us installed in public/javascripts. That’s about all the upgrading you need to do to existing applications.

Do note, though, that all plugins may not be upgraded to be compatible with Rails 1.1. Or you may indeed just have an old version of a plugin that has been updated. Keep an eye out for that.

If you’re wondering why to even bother with Rails 1.1, Scott Raymond currently has the best play-by-play overview of what’s new. We’ll be adding to that with more walkthroughs and hopefully movies around release time.

If you need more documentation, I strongly encourage you to pick up Chad Fowler’s Rails Recipe book. It’s currently out in its 3rd beta release and includes a bunch of great recipes on the new 1.1 features. Including RJS, polymorphic associations (and how to do better tagging with them), join models, integration testing, and more. You can get it as a PDF right now for $21.50.

So help us help you. Test Rails 1.1 with your existing applications. Try building new stuff with it. And let us know if something breaks in the process. We will be taking care of all heinous bugs before release. Thank you all!

In November, PlanetMoon launched Infected, a first-person shooter game for Playstation Portable. The PSP game has two-pieces, one, the actual PSP game (which is C++), and a statistics reporting tool (how many kills did you get, how many people did you infect, where in the world are they). Any time someone wants to grab their stats, it kicks in the PSP Web Browser, which points to a Ruby on Rails server. The team behind this is Jason Wong’si5labs. Jason blogs about some of the challenges of working within the constraints of PSP console.

i5labs also just finished a Zubio chair massage kiosk at the San Francisco Shopping Center. You schedule 10 or 20 minute massage sessions using a touchscreen, then swipe your credit card. The touchscreen system is implemented with Rails. Jason shares details of the code and hardware.

i5labs is also looking to hire a part time Ruby on Rails developer (who could eventually go full time). If you’re interested drop them a note at jobs@i5labs.com.

Last month on the Rails core mailing list, a thread popped up (that went on and on) wherein the idea was proposed that rhtml templates should automatically sanitize output by default. After much back and forth, David suggested those in favor redirect their energies toward a working plugin.

Enter stage left, Erubis. It’s a customized implementation of eRuby that provides a handful of features, notably that <%= %> tags automatically sanitize output. You use <%== %> if you don’t want to sanitize the output. For all those who wish rhtml files were sanitized by default, here is your solution.

Configure your Rails apps to use Erubis templates with ActionView::Base::register_template_handler.

15 months after the first public release, Rails has arrived at the big 1.0. What a journey! We’ve gone through thousands of revisions, tickets, and patches from hundreds of contributors to get here. I’m incredibly proud at the core committer team, the community, and the ecosystem we’ve raised around this framework.

Rails 1.0 is mostly about making all the work we’ve been doing solid. So it’s not packed with new features over 0.14.x, but has spit, polish, and long nights applied to iron out kinks and ensure that it works mostly right, most of the time, for most of the people. Yes, we still have pending tickets, but we will always have pending tickets. If I had accepted that fact back in February, we would probably have been at 2.0 now ;).

Alongside 1.0, we’ve also been working on a new web site, which premieres today as well. It’s a 37signals-powered redesign that streamlines and decrufts us into a much cleaner profile that hopefully will make it even easier for people to get excited and try out Ruby on Rails. It’s online at www.rubyonrails.org and includes two brand new screencasts.

So this is a major milestone for Rails, but we’ve not even begun to think about slowing down. Rails 1.1 is already pretty far along in development and will see some of the biggest upgrades of any Rails release. Hopefully some time in February. But in the mean time, enjoy one oh!

To install Rails 1.0:

gem install rails —include-dependencies

To learn about upgrading a Rails application not already running 0.14.x: Upgrade to 1.0

The only thing you need to do to upgrade from 0.14.x is update your Javascripts using “rake update_javascripts”. You’ll be rocking along with Scriptaculous 1.5 and Prototype 1.4.

It’s been a month since we promised that RC4 would be the final countdown. And counting down we have. We’ve fixed a ton of major, minor, and aesthetic issues and now have a package that we would be very proud to call 1.0. No, it’s not completely spotless. A project of this size with thousands of programmers using it for every application type under the moon will never be. But it’s Pretty Damn Good.

So here it goes: Release candidate 5. This is the final, short pitstop before 1.0 materializes next week. Thus, you’re more than well advised to upgrade and make sure we didn’t leave anything heinous in there. This is the “speak now or forever hold your peace” part of the ceremony.

If you already upgraded to 0.14.x, going to RC5 is completely effortless. Simply call upon the gems to do your bidding with: gem install rails --include-dependencies. And you’ll be serving up your application with all the bugs squashed. On top of that, we’ve thrown in a new adapter for the Firebird database and added a beautiful new index.html that’ll greet you on new applications:

So upgrade, dammit! Now. And stand by as we finish setting up the fireworks planned for next week’s release of the long-awaited 1.0. It’s magical times, my friends, and the spellcasting is just getting started.

Comrades, we are so close to the goal that the relieve should be tastable. The mythical 1.0 release is now penned to be the very next release once we rattle out the heinous bugs from this one. So we need every man, woman, and child at work testing the living daylights out of this final release candidate. Upgrade your apps, start new ones, kick the tires, rev the engine, do it all!

So what’s new? What’s in there to make it pay to upgrade today rather than at 1.0? Lots! In a regular universe, this would have counted as more than merely a 0.0.1 increment. We got a ton of stuff especially for Active Record and the Rails infrastructure.

The new commands

script/server: Will now use lighttpd/FCGI if both are available on the system. This makes for a considerably faster development experience than WEBrick, but is unfortunately a OS X/nix thing only. Windows users will continue to get a WEBrick-powered server launched.

script/plugin: Your gateway to the wonderful world of plugins. Helps you install, manage, and discover new plugins. See script/plugin —help for more.

script/about: Gives you the all the versions for Rails and associates. See the sample.

We’ve added a new dynamic finder that allows you to find or create a new record on the basis of attributes passed, such as saying Tag.find_or_create_by_name(“Summer”). It even works on associations, so page.tags.find_or_create_by_name(“Summer”) is kosher too.

Extensions for association collections is a sexy new way of adding methods to the proxies that all access delegate through. Example:

And finally we’ve really put the spit and polish on the database adapters by adding migration support to all the commercial ones. As well as giving especially the SQL Server one a good loving in general.

Action Controller now has skip_before_filter and skip_after_filter to sidestep certain filters set in superclasses that doesn’t apply to the current controller. Such as specifying :authenticate in ApplicationController, but skiping it in the SignupController.

The ActiveRecordStore no longer only saves when changes have occured, so you can again rely on updated_at being incremented at each page view, and thus rely on it for garbage collection.

Finally we now have an easy way of saying “go back to where you came from” with redirect_to :back.

Upgrading from 0.14.x

It has never been so easy to upgrade to the latest and greatest if you’re on 0.14.x series. You get almost all of it for free simply by installing the latest gems and the rest by running these two commands:

Liquid is a brand new template engine optimized for xhtml and emails. It features a very clean syntax and speedy execution speeds. The main difference to traditional ERb is that it does not rely on eval. This means that no potentially harmful code is executed when a Liquid template is compiled or rendered.

The chief advantage is that you can let your users change templates without having to worry about your data’s security. The templates only see data which you export to them. In Shopify for example you will be able to edit your shop’s templates and emails directly in the admin interface. The templates are stored in the database and rendered directly from it.

Liquid is packaged as a rails plugin for easy installation. In good rails style there is a small movie available showing how to install and use it.

We’ve pushed out the third release candidate for 1.0 of Rails. This release most prominently fixes a memory leak with render_component (which affected Typo among others), the scaffolding bug, and a number of other small things. Please do upgrade. If you’re already running 0.14.1 (RC2), then you don’t need to change anything in the application.

SwitchTower is a utility for executing commands in parallel on multiple machines. It lets you (among many other things) deploy distributed applications with a single command.

When your application is young you may be deploying it to a single machine, which runs the web server, app server, and database all together. In this situation, deploying manually is not unbearably painful. But as your application grows you may find yourself needing to deploy your application to two web servers, four app servers, and two database servers, atomically. This is where SwitchTower steps in as a pain-killer.

Getting Started

Suppose you have an existing Rails application that you want to deploy to a cluster of machines. SwitchTower attempts to make the entire process as painless as possible:

Install SwitchTower. This is as simple as gem install switchtower.

Decorate your application with the necessary SwitchTower files. Just do switchtower --apply-to /path/to/your/app.

Tell SwitchTower where your application code sits and what machines it should deploy to. Just edit config/deploy.rb and fill in the blanks.

Set up your machines so they are ready to receive your application. It’s as easy as rake remote_exec ACTION=setup.

Lastly, deploy your application! Just type rake deploy and let the good times roll.

Other Capabilities

In addition to simply moving your application to the various boxes, SwitchTower attempts to make the task of maintaining your deployment simpler. Suppose something goes wrong while checking out your code—SwitchTower will detect that and roll back the change, on all deployed machines. This means it is much harder to wind up with your application out of sync on the various boxes.

Other things SwitchTower can do, out of the box:

Database migrations on your production database

Enable/disable the web interface (only works with Apache currently)

Restart your application on the application servers

SwitchTower also makes it very simple to override and extend the standard tasks, and to write your own. The tasks use a simple language similar to Rake that allows you to automate many different tasks.

More Information

Want to know more about SwitchTower? There’s an entire user manual full of useful tidbits at http://manuals.rubyonrails.com/read/book/17.

The release of 1.0 is near upon us! It has been a long time in the making, involved a heroic final sprint at RubyConf by the core team, and is a testament to how it’s all been coming together over the last months. Almost three hundred bug fixes, enhancements, and new features have been introduced since 0.13.1 saw the light of day three months ago. That’s on average three per day. So it’s not been a while because of slacking off.

But with all these changes, we want to allow for an extended release-candidate phase before we declare 1.0 a reality. So from today you can get the 1.0 RC 2, which is packaged as version 0.14.1 in the gems.

Over the next two weeks or so, we’re very interested in hearing about bugs and we’ll likely push out a few more release candidates as more and more fixes go in. That said, we can’t fix it all and we surely can’t process all the pending feature enhancements for 1.0. So don’t expect to see an empty Pending Patches or Faults lists. Our main objective is to stamp out the “heinous” bugs: those that significantly affect the many or those that dangerously affect the few.

We’ve returned the default MySQL/Ruby bindings to their former glory, made sure development mode on big applications didn’t get penalized on resetting the object space, and cut WEBricks lust to have a new database connection per request. All changes that actually allows Rails 0.13.1 to live up to the promise of better performance for everyone.

Additionally, we’ve made it possible to use :limit and :offset together with eager loading of has_one and belongs_to associations (has_many and has_and_belongs_to_many will still not work due to the nature of how SQL joins work).

And of course there’s a big bag of delicious script.aculo.us additions and fixes. Be sure to checkout the changelogs for the full scoop as usual:

After the longest gap between releases since Rails was made public and after more than 225 fixes and new features, the final major release before the 1.0 milestone has arrived. We’ve basically put in three new features or fixes every single day for the past 75 days. But what do you care about our labouring efforts? Here’s what’s new in 0.13.0:

Ajax: Visual effects, drag’n’drop, sortable lists, auto-completing text fields
Thomas Fuchs is the latest member of the Rails core contributor group and his amazing set of Javascript magic, entitled script.aculo.us, has been integrated in this release.

It adds a completely rewritten visual effects engine, drag-and-drop capability including sortable lists, and autocompleting text fields to Rails. All building on top of Prototype, the foundation for Ajax in Rails, which has also received a spiffy upgrade by Sam Stephenson.

Hand in hand with the Javascript files is a fresh batch of helper methods that enables to skip the process of writing any Javascript yourself. The new auto_complete_for macro is one of these helpers and it makes adding Google Suggest style auto-completing text fields effortless, as does sortable_element for sortable lists and floats and draggable_element and it’s counterpart drop_receiving_element for drag-and-drop. Try out the live demos and see source code.

We also have Ajaxified progress indicators for file uploads in as an experimental feature in this release. It makes for a much more user-friendly experience uploading large files. See the demo. It’s experimental nature means that it only works on Apache, lighttpd 1.4.x, and only in some environments. Consider it a preview of really cool tech. You need to include ActionController::Base.enable_upload_progress in your environment.rb file to turn it on.

And if you want to perform multiple document updates on a single Ajax call, there’s now the lovely JavascriptHelper#update_element_function, which can be used to generate a stacked return.

Migrations: Agile software needs agile databases
Migrations can manage the evolution of a schema used by several physical databases. It’s a solution to the common problem of adding a field to make a new feature work in your local database, but being unsure of how to push that change to other developers and to the production server. With migrations, you can describe the transformations in self-contained classes that can be checked into version control systems and executed against another database that might be one, two, or five versions behind.

They currently only work with MySQL and PostgreSQL, but with the help of the community, we’ll hopefully have most databases supported in upcoming releases. Read more in the Migration documentation.

Performance: Faster routes, faster everything!
One of our primary goals with this release is to identify and address performance issues. Stefan Kaes took on the task of optimizing the entire code base and contributed numerous speedups with additional help from Jeremy Kemper. An entire rewrite of Routes by Nicholas Seckar makes it nearly seven times faster now. And all this comes with complete backwards compatability. In an effort to make developers more performance-aware, you can now use the new BenchmarkHelper to measure the execution time of a block in a template.

Sweepers: Clean up your caches in a single sweepActionController::Caching::Sweeper is a new approach to sweeping caches that follows a much more intuative one-sweep system where the caches are actually cleared on the observer callbacks. Not just recorded to be cleared during a later filter callback. Sanity is restored to sweeping.

Rendering: One method to bind them all
In the wake of refactoring Active Record’s findAPI, the various render methods got a whole new suit, making the render method the single point of entry for all rendering tasks. Tobias Luetke has a good before and after write up of how render is used now.

Lessons learned from find and render: Consolidate multiple method names that do similar things into one method, use symbols to dictate what used to be done by method name and parametrize with an options hash rather than positional parameters.

FastCGI: Easier to update, more stable in the running
With a new release of a better and up to date FastCGI Ruby binding, and as FastCGI becomes solidified as the deployment mechanism of choice, it’s a good time to have a vastly improved dispatch.fcgi with changes that include:

Send HUP to force the fcgi process to dynamically reload the application

We’ve also extracted a RailsFCGIHandler, so you in the future can update Rails and get improvements without having to get a fresh dispatch.fcgi file.

Routes: Giving them a name and calling them by it
On top of Nicholas Seckar’s entire rewrite of the Routes code come Named Routes by Marcel Molina. Named Routes allow you to reduce code duplication by associating a name with a given route rule. This generates a convenience method that wraps the route rule hash. You define a named route by calling it in your routes.rb in place of the connect method. So, for example:

Email attachements: Make those emails carry the load
Action Mailer now supports sending attachments and multipart messages. Jamis Buck has been leading the way to making ActionMailer robust and feature complete. There’s a fresh new API too that gives specifying emails a more domain-language feel to it. Read all about it in Action Mailer API.

Validations: Run them conditionally and only if
With the new :if option for all validations, you can limit when an attribute is validated, either using a block or a method reference. Examples:

Conditional validations such as the following are made possible:
validates_numericality_of :income, :if => :employed?

Fully backwards compatible!
As has been the norm since around 0.9.0, this release is mindful of backward compatibility, so despite the flow of fixes, improvements, and features, your existing applications won’t need to be updated code-wise. All you need to do to upgrade is get the new gems with gem update rails and then generating the new infrastructure files with rails &lt;your-app-dir>.

You want to overwrite the dispatches, the prototype library, the Rakefile, and the test_helper.rb. Don’t overwrite application_controller.rb, application_helper.rb, or other files you may have tailored, though. It’s always good to do this run on a backup first and check that every things work.

Last major stop before 1.0!
First I want to congratulate the core contributor team on the amazing accomplishment that is this release. The group came together in a stronger-than-ever force especially for the last few weeks up to release. And as the latest member of the group, Thomas Fuchs deserves special praise for giving Rails such a boost of Ajaxiness with script.aculo.us and the associated helpers. It’s incredible that Rails is home to both Prototype and script.aculo.us — the two strongest Javascript libraries for Ajaxians around — and Thomas and Sam deserve much lavish praise for making it happen.

Another shout out for Nicholas Seckar. The second-most recent addition to the group. He has once again delivered goodness all over the code base. From named routes to all those little fixes that makes 0.13 a much more solid experience. You tha man.

And all the hard work is paying off. We’re planning to make 0.13 the last major release before 1.0! We might well see 0.13.1 (but hopefully not 0.13.2) before we start pumping out release candidates for the big one-oh, but it’s getting close. Real close, now.

What you’ve seen here is of course only a tiny sliver of the massive amount of new features and fixes. For the full scoop be sure to devour the changelogs:

There’s nothing like pushing a new major update in order to find bugs in the code when its exposed to a couple of hundred working applications. Thankfully the fixes were almost as swift as the reports. In any case, you’ll definitely want to upgrade to 0.12.1 right away. There’s a good handful of fixes for both Action Pack and Active Record (mostly concerning the new eager loading).

Here’s the dirt, so you don’t have to go look it up. First for Action Pack:

Fixed that :get, :post, and the others should take a flash array as the third argument just like process #1144 [rails@cogentdude.com]

Fixed a problem with Flash.now

Fixed stringification on all assigned hashes. The sacrifice is that assigns[:person] won’t work in testing. Instead assigns[“person”] or assigns(:person) must be used. In other words, the keys of assigns stay strings but we’ve added a method-based accessor to appease the need for symbols.

Fixed that rendering a template would require a connection to the database #1146

Then for Active Record:

Fixed frivilous database queries being triggered with eager loading on empty associations and other things

Fixed order of loading in eager associations

Fixed stray comma when using eager loading and ordering together from has_many associations #1143

The time had come to butcher the piggy-back query and introduce real association loading through outer joins. Behold, the glorious eager loading of associations that makes it silly easy to fetch not 1, 2, but unlimited associations alongside any record in a single query. Turning 50 database queries into 1 never felt this good.

And to match the eager loading, we’re introducing a brand new unified API for Base.find, which works the same whether you’re searching for a specific id, the first record, or all the records. By using named options we alleviate your poor brain for remembering whether the ordering option was argument number 3 or 4.

Better testing
We’ve also slashed the huge number of assertions for testing controllers. In one fell swoop, we’ve gone from around thirty to a shap seven. The remaining assertions are more flexible than before, not nearly as hard to remember, and are followed on by the fantastic new assert_tag, which makes examining the HTML output of an action so much easier than the XHTML/REXML fumblings of yesterday.

More Ajaxing
Of course, we couldn’t make a new release without asserting the undisputed position as the number one framework for doing Ajaxed applications. This release contains a bunch of new smooth effects for visualizing your non-refreshing actions. It’s now much easier to make Ajaxed applications that treat the unfortunate without Javascript nicely with request.xml_http_request? and alternative targets for ajax links and forms. We’ve also added periodically_call_remote that can be used to Ajax-update a given block every so seconds.

In the next release, which will be not very far off, we’re also adding awesome support for both Google Suggest-like search boxes and for upload progress indicators. There’s a powerful team behind pushing the envelope on this. We have so not seen the end of it.

A total of 96 changes, tweaks, and fixes
All these goodies are just the tip of the iceberg, though. There’s a total of 96 new features, changes, tweaks, and fixes packed into this monster of a release. And we didn’t even have time to push in all of the pending patches. How’s that for an action-packed three weeks since the last release?

Fully backwards compatible!
Despite the true onslaught of new features, fixes, and goodies, we’ve managed to keep this release fully backwards compatible with 0.11.1. So you just do a “gem update rails” and all the new stuff is available for use in your current application (to take advantage of the new JS effects you’ll want to copy that one over, though — use rails . in your app dir to get that for free).

The Ajax wave is sweeping across Rails. In this release, we’ve added a :position option to both link_to_remote and form_remote_tag that can be set to either :before, :top, :bottom, or :after. These options make it possible to add new DOM elements to existing lists without replacing the whole list. When working on big lists that are in a fixed order anyway, there’s a considerable speed increase to be had.

Yellow Fade Technique
Additionally, we’ve implemented the first in a hopefully long series of packaged effects. This is the 37signals’ Yellow Fade Technique that’s now available as Effect.Highlight(id) — perfect for highlighting a new element that was just added with Ajax. If you have the Javascript chops to do other effects, please do help out. The wiki discussion page for Ajax in Rails already has great ideas for slide, fadeout, and squish.

VerificationsVerifications in a whole new module for Action Pack that allows you to specify preconditions for you actions. They come in the form of “verify that these parameters are part of the request or redirect the user somewhere else (possibly adding a message to the flash)”. Or said in code:

SQL Server adapter updated
The Micrsoft SQL Server adapter is back in top form supporting both file uploads (albeit still restricted by SQL Server’s 7KB limit) and the new limit style. Thanks to DeLynn Berry for the quick update. Now only the DB2 adapter is not supporting the new limit style.

Loads of fixes
Iconv is no longer required to install Rails (but you’ll want it if you need to send/receive UTF-8 with Action Mailer), you can clone Active Records with floats, the dispatch.fcgi has been fixed, and a bunch of other things. In total, this release has 30 new features, additions, tweaks, and fixes.

Update: No application changes should be required. Just make sure that you copy over the latest prototype.js if you’re using Ajax.

P.S.: Many thanks to Florian Gross for the wonderful code snippet that allows for uploads to RubyForge automatically. This saved me the headache of releasing 12 files by hand one more time. And many thanks to Jamis Buck for the new template used for the API documentation.

With the inclusion of Ajax helpers in Rails 0.11.0, we’ve addressed the most important concern holding back large scale Ajax use: Writing DHTML by hand. Manipulating the DOM by hand is a labor-intensive and error-prone process rife with frustration and cross-browser compatibility. With the Ajax support in Rails, writing manual Javascript/DHTML is (almost) a thing of the past.

Through a handful of helper tags, we’ve exposed an approach that relies on a bare minimum of support on the client-side (XMLHttpRequest and innerHTML) while offloading the generation of page fragments to familiar constructs like ERb and Builder templates. This means that you’ll build your Ajax integration using all the tools you’re familiar with and safely let the Javascript/DOM magic be off-loaded to the Rails helper and library.

Sam Stephenson (hire this guy!) has been the architect behind transforming my meager Javascript attempts into a fully object-oriented library that the Rails helper calls to do its dirty work. He has also done a video demonstrating how he can turn a create form into Ajax in just a few minutes. While this may appear a bit complicated, its mostly because the application Sam’s integrating with lets the controller generate the URL, which normally isn’t the case.

While the Ajax support is certainly the star of this release, we have much more. Another Sam Stephenson goodie is Pagination support, which lets you seamlessly spread the results of a list across multiple pages by combining controller-side and view-side support for pages and navigation.

Also of note is that Rails applications no longer require their own virtual host to be easy to setup. It’s now possible to symlink the public directory from underneath an existing hierarchy, so your application can live under hieraki in /community/hieraki. This should make it considerably easier to install and distribute applications that need to live on shared servers. If you want to make your own application vhost agnostic, have a look at the AssetTagHelper that’ll automatically create the proper paths for images, stylesheets, and the likes.

The Action Mailer gained inbound capabilities in this release. By implementing the receive(email) method, you can target your Action Mailer from fx postfix and have it process incoming emails. We’ve even enhanced TMail to make it easy to process international emails (auto converting to UTF-8) and handling file attachments. See the example in the README and checkout the Howto.

On top of all that there’s a new script/runner for making it easy to call your Rails domain model from CRON, there’s a new Flash module, there’s database indifferent limit/offset, and a truckload of fixes, enhancements, and tweaks.

Updating: If you’re coming from Rails 0.10.1, just run rails . --skip in the root of your application to get the new files. You shouldn’t need to change any code. You will need to clear out all your sessions, though, because of the Flash module upgrade!

We’re plowing through the road map at lightning speed with the release of Rails 0.10.0. There’s so much good stuff in here this time it’s really hard to pick just a few bits to focus on for the overview, but still I have. With Rails 0.10.0, you’ll get:

Routing: Pretty URLs of all flavors and fashions can now be specified using an easy to understand Routing syntax made in Ruby. This means no more wrestling with mod_rewrite in Apache to get custom URL schemes. It means you’re not bound to the traditional /controller/action/id form (the controller and action names don’t even have to be part of the URL!). It also means that the URL parsing and generation is handled by the same configuration, which removes all the labor previously involved in getting your Ruby code to sync with your rewrite rules. That makes it possible to share the same URL configuration across all the web servers supported by Rails. You can seemlessly develop your application on WEBrick and without changes move it to Apache or lighttpd. Read more in the Routing book, see a bunch of routes explained, or dig into the ActionController::Base#url_forAPI documentation.

Web Services: Action Web Service is a whole new add-on framework for Action Pack that enables SOAP with WSDL and XML-RPC web services to be made with Rails ease. You can either describe an existing controller with an API, and let the clients interact with the same methods used to do the HTTP interface, or you can create dedicated service classes that can be bound to a controller. In addition to the support for building web services, we’ve also added convenient wrappers for calling other web services from your application. For getting started, there’s a whole book on Action Web Service that explains how to define, implement, and interact with the web serivce APIs. We also got examples using the GoogleSearch API and the metaWeblogApi.

Components: With components it’s possible to call other actions and controllers for their rendered response while executing another action. You can either delegate the entire response rendering or you can mix a partial response in with your other content. This makes it possible to package functionality in reusable parts and to keep more DRY on application elements that integrate from many sources (like a dashboard). To learn more about components, we have another book, a video showing how to make and call components, and the API docs.

Oracle: In addition to the existing adapters for MySQL, PostgreSQL, SQLite, SQL Server, and DB2, we now also support Oracle as a database option for Active Record. The adapter that made it in is built on top of OCI8 and has been confirmed to work great with Oracle 8i and 9i. Our sixth database adapter is documented in the API.

Honoring Nicholas Seckar and Leon Breedt

The two most important features in this release has been contributed to two relative newcomers to the Rails scene. Nicholas Seckar tried at least three attempts at Routing before we found the one that felt like the best Rails fit. He put an enormous amount of energy into sorting out all the complications and have since helped to improve all parts of Rails. You’ve done a superb job, Nicholas. May potential employeers looking for talent see your name.

Equal thanks goes to Leon Breedt that popped out of nowhere with a whole new framework that followed our established conventions and approach to the dot. The quality of the code and documentation has made a big impression on the existing team of core contributors. And the work has contributed to make us all the much closer to 1.0. Thanks for the excellent work, Leon!

So how far away is Rails 1.0?

Rails 1.0 moved much closer today as we knocked off well over half of the previously announced road map. What we primarily lack now is Packaging and Performance alongside the aim to bring the number of uninvestigated and/or fixed fault tickets down to zero. The current tentative date is end of March/start of April.

Upgrading from Rails 0.9.5 to 0.10.0

If you don’t have any custom URLs defined in your existing application, then it’s a fairly straight forward process to upgrade. If you do have custom URLs, it’s a bit more work, but definitely manageable. Basecamp used a lot of custom URL tricks and it took me under an hour and resulted in 100 lines of code being stripped from the application. In any case, we’ve created a book to guide the upgrade process.

This release is mostly about polishing the Rails by closing holes, deficiencies, and subtle extensions to existing features. The long-awaited Directions and generator upgrade have been postponed to the next release. The highlights of this release is:

Rewritten reloading: Working in development with models and controllers reloading on every request now resembles “the real thing” a lot more by actually removing the model classes before reloading them. This fixes a bunch of subtle bugs and makes it possible to remove a method and see it reflected without restarting the application.

Create and update collections: Through calls like text_field "student[]", "last_name", it’s now much easier to get input tags like input name="student[123][last_name]"..., which together with the fact that Base#create, Base#update, Base#destroy, Base#delete, AssociationCollection#build, and AssociationCollection#create now all accept arrays enables handling of many records at once.

Stopping after render/redirect: Any before_filter can now terminate the chain by calling render or redirect and the pattern of redirect-and-return now works again. The first call to either render or redirect wins as well and subsequent calls are ignored.

That’s just three of the 37 changes, fixes, and additions available in Rails 0.9.5. You can read the full story in the changelogs for Active Record, Action Pack, and Rails.

This release shouldn’t require any changes to your application if you’re coming from Rails 0.9.4 unless you were relying on const_missing to load non-AR/AO/AC classes. In that case, you’ll have to start being explicit with require_dependency for the reloading to be triggered.

Seems like the 0.9.4 release required a public launch in order to find the last snags. No game, no pain, or something. The changes are:

Action Mailer

Fixed sending of emails to use Tmail#from not the deprecated Tmail#from_address

Action Pack

Fixed bug in page caching that prevented it from working at all

Fixed a bug where cookies wouldn’t be set if a symbol was used instead of a string as the key

Added assert_cookie_equal to assert the contents of a named cookie

Active Record

Fixed that the belongs_to and has_one proxy would fail a test like ‘if project.manager’ — this unfortunately also means that you can’t call methods like project.manager.build unless there already is a manager on the project #492 [Tim Bates]

Fixed that the Ruby/MySQL adapter wouldn’t connect if the password was empty #503 [Pelle]

Another incredibly strong release sees the light of day as we move one step closer to the mythical 1.0. This release tackles one of the five steps on the roadmap in form of caching as well as adding a bunch of other cool stuff.

Conditional filters: It’s now possible to limit the actions that a given filter will apply to within a controller using either :only or :except. Like, before_filter :authorize, :only => [ :edit, :delete ]. Read more

Associating unsaved objects: Associations between unsaved objects makes it much easier to build big graphs that only makes sense to be saved together. Read more

Database compatibility: SQLite3 is now supported by the sqlite adapter and MySQL 4.1.1+ is also supported by the included Ruby/MySQL driver.

Numeric bytes and time: Rails has taken upon itself to extend Ruby in a few spots, such as adding the possibility for expressions like 45.kilobytes + 2.3.megabytes and 45.minutes + 2.hours + 1.fortnight. Readmore

Those were the highlights, but Rails 0.9.4 includes no less than 50 changes, fixes, and features. You can read the full story in the changelogs for Active Record, Action Pack, and Rails.

This release shouldn’t require any changes to your application if you’re coming from Rails 0.9.3.

Rails is now fully compatible with Ruby 1.8.2, which we advice all to upgrade to as soon as possible. It contains a year’s worth of bug fixes for Ruby, so it’s great finally to be able to use the new version with Rails. But that is not all we got in store for 0.9.3. A few of the highlights are:

Automated optimistic locking: Just add the field lock_version to your table and the associated class will be governed by optimistic locking that’ll raise an exception if a stale object attempts to save.

Dynamic finders: Finders like Person.find_by_user_name, Payment.find_by_amount, and even Person.find_by_user_name_and_password are now available with no code at all. Any column can be used and combined with other columns in the new dynamic finders.