InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

Engine Yard Has Taken Over Ruby 1.8.6 Maintenance

Posted by Mirko Stocker on May 26, 2009

Sections
Enterprise Architecture,
Operations & Infrastructure,
Process & Practices,
Architecture & Design,
Development
Topics
Announcements ,
Ruby ,
Runtimes
Tags
Releases

Engine Yard recently took over the maintenance of the Ruby 1.8.6 branch:

It is with great excitement that we want to announce the transition of legacy maintenance duties for Ruby 1.8.6 from the capable hands of Urabe Shyouhei to Engine Yard. Going forward, I will be the primary point of contact for bug and security fixes for the 1.8.6 branch of Ruby [..].

Engine Yard has more than 6000 virtual machines running on Ruby 1.8.6 (see "Engine Yard to Take Over Ruby 1.8.6 Maintenance?" on InfoQ), so they have an interest in keeping this specific version alive for customers that can't or don't want to upgrade.

InfoQ had the chance to talk to Kirk Haines, Software Developer at Engine Yard and the actual maintainer of Ruby 1.8.6.

Are the MBARI patches coming to 1.8.6?

We like the MBARI patches, so we're working with the 1.8.7+ team on a strategy to put them in the entire 1.8 line. We think there are a few more bugs to be shaken out before we can do that, and the 1.8.7+ team needs to be comfortable.

Any other patches (for example from the Phusion/Ruby Enterprise Edition team) that are going to be applied?

Again, we want to be conservative as a maintainer, and something like Phusion should be consistent between 1.8.6+ and 1.8.7+, so it's another thing to work on with the Japanese team. The original concern with the Phusion patch was that it impacted general performance because its garbage collection was O(N), and was generally considered different enough to be something close to a fork. This may no longer be the case, but frankly this is why there needs to be a permanent maintainer for 1.8.6, so we can figure this stuff out.

There were rumors about moving Ruby 1.8.6 to GitHub, are these true? 

This is not true. We may keep a github mirror for development purposes, but the true source will continue to be the svn repo.

What are your plans for 1.8.6's future?

We want to maintain a clean, stable version of 1.8.6 that maintains 1.8.6 API's and behaviors, while backporting the best of performance, security and bug patches and fixes. We intend to maintain our 1.8.6 commitment for at least the next two years.

See the announcement from Engine Yard for more information and comments.

What do you think about Engine Yard taking over Ruby 1.8.6 maintenance?

No comments

Watch Thread Reply

Educational Content

New-age Transactional Systems - Not Your Grandpa's OLTP

John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.

Cool Code

Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.

Collaboration: At the Extremities of Extreme

Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.

Yesod Web Framework

Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).

Transactions without Transactions

Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.

Attila Szegedi on JVM and GC Performance Tuning at Twitter

Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.

Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.