是 RailsConf 了，我们决心在此之前发布最终版的 Rails 5.2。因此，这可能是发布前最后一个候选版本。我们投入大量精力来解决 Active Storage 的所有问题，特别是现在越来越多的应用程序在生产中开始使用它。
您可以浏览自年初发布第一个候选版本以来的 近 200 次提交，以查看已修复的所有内容。
如果您打算启动一个新的应用程序，我对自己这次发布信心十足，建议您从此 RC2 开始。如果您喜欢掌握最新版本，那么现在也是更新现有应用程序的好时机。
您可以在最新完成的 版本说明 中更详细地阅读 Rails 5.2 中 所有新功能。
享受 Rails 5.2，希望在 RailsConf 上见到各位，大约一个月后！
Rails 中的文件上传处理太难了，已经持续太久。当然，有很多优秀的插件可用，但我们早已应该将某些内容直接纳入框架中了。现在，我们做到了！
在 Rails 5.2 中使用新的 Active Storage 框架，我们解决了直接将文件上传到云环境中的现代化方法。开箱即用，它可支持亚马逊 S3、谷歌 Cloud Storage 和 Microsoft Azure Cloud File Storage。
如果您处理的是图像，可以在正在处理时创建变体。如果您处理的是视频或 PDF 文件，可以在处理时创建预览。无论文件类型如何，都可以异步分析上传内容以提取元数据。
Active Storage 由乔治·克拉格霍恩和鄙人从 Basecamp 3 中提取。因此，此框架不仅已经在生产环境中使用，而且是源自生产环境的。这保证了提取式设计！
说到提取，杰勒米·戴尔已经解开了 Basecamp 中用于使用 Redis 执行常规部分、片段和其他 Rails 缓存任务的一堆乱麻般的 Hack。这里有一个闪亮的全新 Redis 缓存存储，它将这些年的各种老练 Hack 都整合到一个任何人都可以使用一个内聚单元中。
这款新的 Redis 缓存存储支持 Redis::Distributed，可跨 Redis 实现类似 Memcached 的分片。它具有容错性，因此将把失败当作失误处理，而不是引发异常来中断请求。它甚至支持分布式 MGET，以实现完整的部分集合缓存优化。
这一切得益于高速缓存效率所带来的巨大飞跃，高速缓存效率的提升是由默认启用的 密钥循环利用 和 压缩 带来的。对于 Basecamp 而言，这意味着缓存有效期提高了 100 倍！我们的缓存使用寿命从短至一天，延长至好几个月。如果你使用部分高速缓存和套娃策略，在这两种变更的支持下，你的缓存有效期将极大程度地提升。
我们还采用了 HTTP/2 中的精华——早期提示，这项功能由 Aaron Patterson 和 Eileen Uchitelle 共同完成。这意味着，我们可以自动指示网络服务器及早发送所需的样式表和 JavaScript 资产。这意味着能够更快速地提供完整页面，因为没有人会拒绝这一点，不是吗？
在性能话题上，Rails 现在默认 Gemfile 中附带 Bootsnap，这是我们的朋友在 Shopify 创建的。通常情况下，它可以将应用程序启动时间减少 50% 以上。
Rails 一直走在让你的网络应用程序更加安全的道路的最前沿，以内置 CSRF 和 XSS 保护而闻名，并且我们在 Rails 5.2 中通过 添加新 DSL 进一步增强了此功能，该功能允许你为自己的应用程序配置 内容安全策略。你可以配置一个全局默认策略，然后根据具体资源覆盖它，甚至使用 lambda 将每个请求的值注入到标头中，例如多租户应用程序中的帐户子域。
但这并不是全部令人惊讶的新奇事物。在 Rails 5.1 中，我们添加了 加密密码。这些密码类似于旧密码，但，嗯，更隐秘，因为，你知道，加密！让人困惑？是的。你为什么要想要那些实际上并不安全的密码？嗯，你不需要。
在 Rails 5.2 中，我们通过弃用两种不同的密码并引入称为 凭据 的新共享概念来纠正混乱。凭据，例如 AWS 访问密钥以及其他形式的登录名和密码，是密码的主要用例，为什么不直接称其为凭据。所以就是这么回事！
凭据始终是加密的。这意味着它们可以安全地检入版本控制，只要你把密钥排除在外即可。这意味着原子部署，无需再处理一系列环境变量以及将应用程序所需的所有凭据放在一个安全可靠的地方所带来的其他好处。
此外，我们已经开放了凭据背后的 API 接口，这样你便可以轻松处理其他加密配置、密钥和文件。
自 Rails 5.1 起，我们也取得了与 Webpacker 合作的重大进展。因此，Rails 5.2 旨在与新的 Webpacker 3.0 版本完美搭配。Rails 通过 Webpack 运营预先配置的构建管道，充分采用现代 JavaScript。我们不断加强这种关系。