万一您错过了新闻：Edge Rails 正在苏醒，Rails 3 的更改已开始在 Github 的 master 分支中显现。所以本周有很多值得讨论的内容。如果您想了解更多关于 Rails 3 重构至今的技术细节，可以查看 Yehuda Katz 的详细博客文章。
我应该使用哪个分支？
Rails 3.0 的开发正在 Github 上的 Rails 仓库的 master 分支上进行。如果您想跟上所有最新的更改，这就是要跟踪的分支——但请注意，目前这是 alpha 版本代码。使用 master 分支构建一个工作的 Rails 应用程序是完全可行的。Rails 核心团队致力于确保 master 分支通过所有测试，事实上，改进我们的测试覆盖率和持续集成策略都是 Rails 3 改进的一部分。但重要的是要认识到，Rails 的更改将导致许多插件需要重写才能与 Rails 3 兼容（当然，一些插件需要的更新比其他插件多）。这将使得 Rails 3 在相当长一段时间内难以用于大规模生产部署。
对于现有的生产应用程序，您应该跟踪 Github 上的 2-3-stable 分支的更改。此分支包含 2.3 版本代码的错误修复和改进，并且应继续与您已在使用中的插件和代码保持兼容。
我应该提交补丁到 Rails 吗？
当然！Rails 一直是一个社区努力的成果，Rails 3 也不会改变这一点。我们欢迎为 Rails 2.3 或 Rails 3.0 提交补丁——请在您的 Lighthouse 工单中使用相应的标签（2-3-stable 或 3.0），以便于区分您已测试并基于哪个分支提交了补丁。 《贡献 Rails 指南》将帮助您了解提交 Rails 补丁的具体流程。
David 在去年 12 月概述了 Rails 3 的整体愿景，这仍然是基本计划。如果您有特别想参与的某个部分，Ruby on Rails: Core 邮件列表将帮助您与开发人员联系以协调计划——并可能节省一些精力。大多数主要工作已经开始，但我们知道社区的想法和贡献对于 Rails 3 的成功至关重要。
Rails 2.3.x 更改
说到 Rails 2.3，过去几周已部署了一些错误修复，以及一个有趣的增强功能：`ActiveRecord::Base#touch`。其理念是为您提供一个快捷方式，将当前时间推送到记录中的 `updated_at` 或 `updated_on` 时间戳字段。
@customer.touch
这个功能比节省几个按键更重要，因为它也作为 `belongs_to` 关联的一个选项来实现。
class Order < ActiveRecord::Base
belongs_to :customer, :touch => :last_order_update
end
有了此声明，保存或销毁订单对象将触发相应的父客户对象。当您在这种情况下尝试使父对象的缓存副本失效时，这会非常有用。
Rails 3.0 更改
`ActiveRecord::Base#touch` 也同时添加到 Rails 3.0 和 2.3 分支。总的来说，情况应该是这样的：Rails 2.3 的新功能将延续到 Rails 3。核心团队正在努力确保在进行版本切换时易于升级和兼容。但本周还有许多其他仅适用于 Rails 3 的更改：这就是本文其余部分将要讨论的内容。
模块组织
Rails 代码中有一些地方存在多层级的包含、继承和设置。为了更容易理解正在发生的事情，Rails 3 引入了新的 `depends_on`、`use` 和 `setup` 抽象。这些可以使代码的意图在阅读时更加清晰。
module AbstractController
module Helpers
depends_on Renderer
setup do
...
end
...
end
end
module ActionController
class Base2 < AbstractBase
use AbstractController::Callbacks
use AbstractController::Helpers
...
end
end
AbstractController
迄今为止 Rails 3 中最大的架构性变化可能是引入了 `AbstractController` 基类。这是 `ActionController::Base` 和 `ActionMailer::Base` 之间共性的新实现，最终将作为 Rails 对 Merb 的 parts 的基础类。其意图不是提供插件或应用程序直接使用的代码，而是构建一个可靠的底层 API，供其他组件依赖。例如，`AbstractController` 的使用者将能够实现自己的模板路径查找逻辑，或为基本的 `render` 方法添加其他选项。
ActionDispatch
另一个内部架构性变化是引入了 `ActionDispatch`。作为 Action Pack 的新成员，`ActionDispatch` 容纳了所有之前塞入 `ActionController` 的各种 HTTP 库和中间件，包括请求处理、参数解析、状态码以及我们打包的 Rack。 提交
定义接口
Rails 3 工作目标之一是清晰地区分插件和应用程序代码可以依赖的公共 API 方法，以及可能发生变化的 Rails 内部实现。例如，您可以查看为 `ActionView::Template` 进行的一些重构。这里的改变是识别那些不被其他类使用的私有方法。这立即使得类的预期 API 更易于理解，并且从长远来看，将有助于我们与插件就如何与核心代码交互达成一致。在当前接口正式确定后，很可能会进行缩减，以实现更清晰的外部 API。 提交
AJAX 和认证令牌
如果您手工编写了很多 JavaScript，您就会发现需要在请求中包含 Rails 认证令牌的麻烦。对这些问题的深入分析表明，AJAX 请求不需要这些令牌，因为同源策略可以保护它们。因此，Rails 3 不再检查 AJAX 请求中的令牌，这又少了一个烦人的 JavaScript 代码。
测试改进
Rails 3 的另一个关注点是将内部测试提升到当前最佳实践水平。现有代码中有许多测试不够系统化——更改已通过测试覆盖率进行检查，但没有人尝试确保所有正常的“理想”代码路径都经过全面测试。要了解此领域的一些进展，请查看 `actionpack/test/new_base` 中的一些测试文件（new_base 代码是 `ActionController::Base` 的重写进行中）。此外，还在积极改进我们的持续集成流程，并构建一些基本的高级集成测试来测试整个 Rails。
收尾工作
一些 Rails 2.3 功能目前在 master 分支中尚未实现。一些更改无法与新架构顺利合并，另一些则以不同的方式重新实现。您可以在此提交消息中找到一些具体信息，但缺失的部分包括开发模式渲染的性能提升、生产环境的模板重新编译以及一些模板选择逻辑。负责 Rails 3 的开发人员已表示，他们打算尽快恢复功能对等性。事实上，对 rails-dev-boost 更改的第一轮修改已经提交。
已移除：CGI 支持
Rails 3 将不再支持直接的 CGI 分发。这在 Rails 2.3 中已被弃用，所以其被完全移除应该不会令人生疑。但是，如果您出于某种原因需要使用 CGI，请记住它仍然可以通过 Rack 支持。 提交