Rails 5.0 在大约八个月前发布，现在，3500 次提交后，我们已经接近下一个重大版本发布了。Rails 5.1 版将是一款怎样的版本呢？我们在兑现长期承诺和关键的人机工程学方面取得了长足进步，同时还清理了许多弃用的代码。
让我带大家了解一下亮点
这些年来，我们与 JavaScript 一直保持着一种风雨飘摇、甚至近乎激烈争论的关系。但现在已经过去了。尤其是在 ES6 和 Yarn、Webpack 等包和编译工具问世后，JavaScript 在过去几年中有了长足的进步。Rails 正张开双臂迎接这两个解决方案，并让过往的矛盾烟消云散。
JavaScript 和 Ruby 在语言设计（如果不是生态系统管理）方面有着密切的哲学联系。让我们关注于我们共同的方面，并在一些关键的指导约定帮助下，帮助 Rails 程序员从 JavaScript 中提取最佳内容。
Rails 5.1 中的改进主要集中于三大方面
通过 Yarn 从 NPM 管理 JavaScript 依赖项。可以将 Yarn 想象成 JavaScript 的 Bundler（它甚至 包含了 Yehuda Katz！）。这样一来，就可以轻松依赖于 React 等库或 NPM 中的任何其他内容。您通过 Yarn 依赖的所有内容都可以通过资产管道进行必需处理，就像供应商依赖项一样。只要使用 binstub bin/yarn 就可以添加依赖项。
可使用 Webpack 编译 JavaScript。虽然 JavaScript 有一百万种不同的模块捆绑/编译器，但 Webpack 正在迅速成为首选。我们已经通过新的 Webpacker gem 实现了轻松通过 Rails 使用 Webpack 的功能，您可以在使用 --webpack 的新项目上自动配置该 gem。这与资产管道完全兼容，您可以继续使用它来处理图像、字体、声音等任何内容。您甚至可以在资产管道上使用一些 JavaScript，也可以通过 Webpack 来实现这一点。所有内容都通过默认启用的 Yarn 管理。
将 jQuery 放弃为默认依赖项。我们曾经需要 jQuery 来提供诸如 data-remote、data-confirm 和其他 Rails UJS 部分等功能。由于我们已 将 rails-ujs 重写为使用原生 JavaScript，因此不再需要此依赖项。当然，您仍然可以自由使用 jQuery，但不再必须使用。
感谢 Liceth Ovalles 在 Yarn 集成方面所做的工作，感谢 Dangyi Liu 在 rails-ujs 方面所做的工作，以及 Guillermo Iguaran 对整个项目的督导！
在我2014 年在 RailsConf 发表主题演讲中，我详细阐述了过度关注单元测试（和 TDD）是如何让我们误入歧途的。虽然单元测试是一个完整测试解决方案的一部分，但它们并不是最重要的部分。从控制器到模型和视图全面验证行为的集成测试应发挥更重要的作用。Rails 已经为这些内置问题找到了一个很好的答案。
但是，如果系统依赖于 JavaScript，则集成测试无法帮助您测试整个系统。当今大多数主要的 Web 系统至少在一定程度上依赖于 JavaScript。这就是由真实浏览器驱动的系统测试发挥作用的地方。
长期以来，Ruby 中有一个名为Capybara的类似系统测试解决方案。而正确配置 Rails 只是一段旅程。因此，现在我们已经将它们直接构建到框架中！您将获得 Capybara 的可爱包装，它经过预先配置以适用于 Chrome 并且经过增强以提供故障屏幕截图作为 Action Dispatch 的一部分。您也不必再担心额外的数据库清理策略，因为内置事务测试现在会回滚系统测试更改。
这些测试并非没有权衡取舍。当然，在整个浏览器设置中运行仍然比使用存根数据库测试模型要慢。但这也会测试更多内容。您最好熟悉系统测试，并将其作为测试解决方案的一部分。
感谢Eileen M. Uchitelle从Basecamp中提取出此内容！
如果您正在检查未经伪装的生产口令、API 密钥和其他密钥进入您的版本控制系统，那么您做错了。那是不安全的，您应该停止！这是一个简单的处方，但在没有对您应该做些什么的连贯答案的情况下，它也没有什么帮助。
人们长期以来一直在加载 ENV 来存储这些秘密或使用各种其他解决方案。ENV 模型有很多权衡取舍和缺点，其中最重要的是您仍然需要在其他地方真正存储这些秘密。
受Ara T. Howard的sekrets gem的启发，我们已经将加密密钥管理构建到 Rails 5.1中。您可以使用bin/rails secrets:setup设置一个新的加密密钥文件。这会生成一个您将存储在存储库外部的主密钥，但允许您将实际的生产密钥提交到版本控制中。然后，这些密钥在生产环境中通过注入的关键文件或通过 ENV 中的 RAILS_MASTER_KEY 解密。
感谢 Kasper Timm Hansen 为这项工作所做的贡献，也要感谢为这项工作提供灵感的 Ara！
Action Mailer 采用 Action Controller 为模型。它通过 Abstract Controller 共享基础，但在共享操作间逻辑时，长期以来一直不如它的 Controller 姐妹。p
在 Action Controller 中，经常使用 before_action 和类似回调来提取适用于多个操作的逻辑。这是可行的，因为在调用操作之前可以提供 params 哈希。但在 Action Mailer 中，我们一直使用带有显式参数的普通方法签名，因此这些参数在操作之前运行的过滤器中不可用。
使用 带有参数的邮件，我们现在允许你使用参数调用邮件，这些参数与 Controller 中相同，可以在调用操作之前提供。这结合默认的 to/from/reply_to 标头，极大地减少了某些邮件操作的 DRY。
它完全向后兼容，你只需转换最有可能从提取中受益的邮件即可。
我们有一个非常简单且好用的 API，可用于声明新的资源路由。但是，如果你希望添加新的、基于参数确定最终目标的编程路由，好吧，你需要使用一些助手和其他混乱方法自己划船。
使用直接路由，现在可声明编程路由，它具有 Ruby 的完全功能，可以根据传递的参数执行不同的操作。
使用已解析路由，你可以直接根据兼容方法为模型重新编程 polymorphic 查询。因此，这允许你将 link_to @comment 变成像 message_path(@comment.parent, anchor: "comment_#{@comment.id}") 这样的最终路由。
感谢 Andrew White 完成这项工作！
长期以来，我们有两种并行结构用于创建表单。一种是基于 form_for 记录的结构，其中我们使用约定优先于配置来提取详细信息，另一种是使用 form_tag 手动配置的表单。现在，我们已经通过 form_with 将这两个层次结构统一。一个单一的根树，你可以通过推断记录或手动进行配置。它更简洁、更简单了。
也要感谢 Kasper Timm Hansen 对此所做的贡献！
除了重点内容外，我们还对所有框架进行了数百项其他修复和改进。请仔细阅读变更日志以熟悉所有好处。
适用于 Rails 5.1 的版本管理员为 Rafael França。他将在测试版、候选版本及 RailsConf 2017 预期的最终版本中带我们进行指导。
根据我们的 维护策略，Rails 5.1 版本发布后，仅 5.1.x 适用错误修复，常规安全问题则适用于 5.1.x 和 5.0.x，而严重安全问题则适用于 5.1.x、5.0.x 和 4.2.x。这意味着 4.x 和更低版本将基本不受支持！
请帮助我们测试此 Rails Beta 版本。当我们在新版本、Beta 测试、候选版本上投入大量精力时，却让人们在最终版本发布后的第一周报告各种问题，这种体验总是令人沮丧的。Basecamp 3 已在生产环境中运行此 Beta 版本。这是 Rails 5.0 的增量升级。请履行您的社区义务，帮助我们发布一个稳定的 5.1，无需立即发布 5.1.1。谢谢！Gracias！Merci！TAK！