Rails 5.0 发布至今仅仅八个月，而现在，经过大约 3500 次提交，我们即将迎来下一个重要版本。这个 5.1 版本将会是多么重要！我们在长期承诺和关键的人体工程学方面取得了巨大进展，同时也清理了大量已弃用的代码。
让我带您回顾一下其中的亮点。
多年来，我们与 JavaScript 的关系一直波折，甚至充满争议。但这一切都已成为过去。近年来，JavaScript 取得了长足的进步，特别是随着 ES6 的出现，以及 Yarn 和 Webpack 等包管理和编译工具的普及。Rails 正张开双臂拥抱这些解决方案，让过去的恩怨随风而去。
JavaScript 和 Ruby 在语言设计方面有着深刻的哲学联系，尽管在生态系统管理方面可能有所不同。让我们关注共同点，并在一些关键的指导约定下，帮助 Rails 程序员更好地利用 JavaScript。
Rails 5.1 的改进主要集中在三个方面：
通过 Yarn 管理 NPM 上的 JavaScript 依赖。 将 Yarn 想象成 JavaScript 的 Bundler（它甚至有 Yehuda Katz 的参与！）。这使得依赖 React 或 NPM 上的任何其他库变得容易。通过 Yarn 依赖的所有内容都可以像 vendor 化的依赖一样，在 asset pipeline 中进行 require。只需使用 bin/yarn binstub 添加依赖。
可选地使用 Webpack 编译 JavaScript。 尽管有无数的 JavaScript 模块打包器/编译器，Webpack 正迅速成为首选。通过新的 Webpacker gem，我们使其易于与 Rails 结合使用，您可以使用 --webpack 在新项目中自动配置。这与 asset pipeline 完全兼容，您可以继续将其用于图片、字体、声音等。您甚至可以将部分 JavaScript 放在 asset pipeline 中，部分通过 Webpack 处理。所有这些都通过默认启用的 Yarn 进行管理。
移除 jQuery 作为默认依赖。 以前，为了提供 data-remote、data-confirm 等功能以及 Rails UJS 的其他部分，我们需要 jQuery。现在这个依赖不再是必需的，因为我们已将 rails-ujs 重写为使用 vanilla 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 共享底层，但在逻辑共享方面，它一直不如其控制器“表亲”方便。
在 Action Controller 中，通常使用 before_action 和类似的 callbacks 来提取适用于多个 action 的逻辑。这之所以可行，是因为在 action 被调用之前，params hash 已经可用。但在 Action Mailer 中，我们一直使用常规的方法签名和显式参数，因此这些参数无法被在 action 之前运行的过滤器使用。
通过 Parameterized Mailers，我们现在为您提供了使用参数调用 mailer 的选项，这些参数与控制器中的参数一样，在 action 调用之前就可以获取。这结合默认的 to/from/reply_to 邮件头，极大地减少了一些 mailer action 中的重复代码。
它完全向后兼容，您可以先将那些最能从中受益的 mailer 转换为参数化形式。
我们有一个简单易用的 API 来声明新的资源路由。但是，如果您想添加具有逻辑以根据参数确定最终目标的编程路由，那么您必须自行处理，使用 helpers 等混乱的方法。
通过 directed routes，您现在可以声明编程路由，它们拥有 Ruby 的全部强大功能，可以根据传递的参数执行不同的操作。
通过 resolved routes，您可以直接将模型的多态查找重写为兼容方法。因此，这允许您将 link_to @comment 转换为最终路由，例如 message_path(@comment.parent, anchor: "comment_#{@comment.id}")。
感谢 Andrew White 完成所有这些工作！
我们长期以来有两种创建表单的并行结构。一种是基于记录的 form_for，我们通过约定优于配置来提取细节，另一种是手动配置的 form_tag。现在，我们通过 form_with 统一了这两个层级。一个单一的根树，您可以通过推断的记录或手动进行配置。它更简洁、更简单。
再次感谢 Kasper Timm Hansen 完成这项工作！
除了亮点之外，我们在所有框架中还进行了数百项其他修复和改进。请仔细阅读 CHANGELOGs，以便您了解所有新功能。
Rails 5.1 的发布经理是 Rafael França。他将在 beta 版、发布候选版直至最终发布的过程中全程陪伴我们，为 2017 年 RailsConf 做准备。
根据我们的维护政策，Rails 5.1 的发布意味着 bug 修复将仅适用于 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！