当前 Ruby 的境地很尴尬，它有很多不同的实现 / 分支，而且特性迥异——当然这并不是针对其竞争者 JRuby、Rubinius、MagLev 及 IronRuby 来说的，而是其 1.8.6、1.8.7 和 1.9.1 这三个版本。
几周前 Ruby 1.9.1 终于发布了其稳定版，同时也开始不断劝说开发者从 1.8 版上迁移过来。去年 5 月发布的 Ruby 1.8.7 通过移植一些特性和API 变更来简化从1.8 迁移到1.9 的代价。但遗憾的是，一些库和框架并非只是与该版本的Ruby 搭配使用，这导致了很多人对1.8.7 敬而远之。Ruby 的其他实现的进度也是相当的慢，最后造成了 JRuby 完全跳过了 1.8.7 的结果。
这就是 Matz 及核心的开发者所维护的 Ruby 中有三个不兼容版本的原因所在了。大家就该情况展开了一系列讨论，最后建议 Ruby 核心团队将 1.8.6 版的维护工作转交给他人，而当前的维护者 maintainer Shyouhei 也乐意这么做。来自于Engineyard（已在Ruby 1.8.6 上运行了大约6000 个虚拟机，他们不打算升级）的Ezra Zygmuntowicz“很高兴接受Ruby 1.8.6 的维护工作”， Shyouhei 也对其表示欢迎：“如果没有人申请的话，我很愿意将 Ruby 1.8.6 的维护工作交你接管”。
有些问题仍在讨论当中，比如是否将其迁移到 GitHub 上及迁移到哪个分支上。Brent Roman 的“MBARI”补丁看起来很有希望，它修复了一些长期存在的内存泄漏问题和 Ruby GC 的一些问题（InfoQ已经报道过 MBARI 补丁及其作用）。下面的内容来自于 Ezra 的邮件列表：
我们支持 Brent 将这些补丁打到当前的 1.8.6 上并希望他们成为主线上的 1.8.6、1.8.7 及 1.8.* 的一部分。这些补丁并不会破坏任何 API 或是产生向后兼容问题，相反他们能极大的改进我们测试的所有 Ruby 应用的内存问题。在测试中我们看到 Ruby 应用的 GC 占据了 45% 的 CPU 时间，而应用这些补丁能极大的降低 CPU 的占用率。
但这对于开发者选择 Ruby 版本的决策来说却没有什么用处，Ruby 1.8.6 仍会继续存在并得到维护。你还在使用 1.8.6 么，如果是的话，为什么不升级呢？
暂无签名
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论