Multiple Ruby Version Support on Heroku

Maximizing parity between development and production environments is a best practice for minimizing surprises at deployment time. The version of language VM you're using is no exception. One approach to this is to specify it using the same dependency management tool used to specify the versions of libraries your app uses. Clojure uses this technique with Leinigen, Scala with SBT, and Node.js with NPM. In each case, Heroku reads the dependency file during slug compile and uses the version of the language that you specify.

Today, we're pleased to announce that we've added support for specifying a Ruby version to Gem Bundler, the dependency management tool for Ruby. This will allow you to specify a version of Ruby to be used in your Ruby app on Heroku.

Try it out:

$ gem install bundler --pre

In your Gemfile:

source 'http://rubygems.org'

ruby '1.9.3'
gem  'rails', '3.2.3'

Then:

$ bundle install
$ git add Gemfile
$ git commit -m 'use Ruby 1.9.3'
$ git push heroku master

Prove that you're running 1.9.3:

$ heroku run 'ruby -v'
ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-linux]

$ heroku run 'ruby -e "puts RUBY_VERSION"'
1.9.3

Patch Versions

While you can specify the version of Ruby for you app, you can't specify a patch version, such as Ruby 1.9.2-p290. Ruby patches often include important bug and security fixes and are extremely compatible. Heroku will provide the most secure patch level of whatever minor version number you request.

Thanks

Thanks to Terence Lee Heroku Ruby team member and bundler maintainer for the additional support of ruby versions to the Heroku Ruby Buildpack and orchestrated the release of Bundler 1.2.0. Also thanks to Yehuda Katz and the entire Bundler team for helping get this release out the door.

Matz Named 2011 Free Software Award Winner

We are pleased to announce that Yukihiro "Matz" Matsumoto, the creator of Ruby and Heroku's Chief Ruby Architect, has received the 2011 annual Advancement of Free Software Award. Presented by Richard Stallman and on behalf of the Free Software Foundation, the award is given each year to those who have greatly contributed to the freedom of software.

This is great news for Matz, who has dedicated over 20 years to the development of free software including the creation of the Ruby programming language. While writing Ruby he chose to focus on programmer happiness and productivity, and the result has been extraordinary. The popularity of the language, helped in part by the Rails framework, has encouraged a new generation of free software advocates who together have released more than 36,000 freely downloadable Ruby libraries known as Gems.

This award is also a huge win for Ruby. It's a recognition of Ruby's importance, will bring more people into the community, and encourages more developers to share their work. If you'd like to contribute to Ruby, visit the ruby core page where you can learn how to submit a patch or file a bug report.

We're very proud of the Ruby community as a whole, and for Matz and all of his accomplishments. So please join us today, along with the Free Software Foundation, in thanking him for all of his hard work.

Defaulting to Ruby 1.9.2

Heroku is fully behind Ruby 1.9.2 as the new gold standard for production Ruby apps. Over the past few months, we’ve seen more and more developers move to the Bamboo 1.9.2 stack. It’s fast, stable, and increasingly sees excellent support throughout the community.

In February, we said that we’d be reviewing the state of 1.9.2 support with the eventual goal of switching the default for new Ruby apps on Heroku from 1.8.7 to 1.9.2. Today, we’re announcing the date of that switchover.

As of June 1st, 2011, all new Ruby applications on Heroku will be run on Ruby 1.9.2 by default. (Existing applications won’t be affected, and you can always create a new application on 1.8.7 by running heroku create --stack bamboo-ree-1.8.7.)

But there’s no need to wait till June – get started with a Ruby 1.9.2 app on Heroku today with the following command:

$ heroku create --stack bamboo-mri-1.9.2

The Path Forward: Ruby 1.9.2

At Heroku, we’ve been watching the progress of MRI very carefully for a while now; we added support for 1.9.1 nearly a year ago and 1.9.2 more recently, and we’ve seen thousands of apps created and running successfully on the 1.9 series of VMs. At the same time, we’ve seen the community as a whole recognize the importance of 1.9 by migrating libraries and gems to it and providing resources and tutorials on upgrading.

Today, Heroku is putting our full support behind Ruby 1.9.2 as the future of MRI. It is a stable, battle-tested, production-quality Ruby, and we’re excited to see it become the mainstay for future Ruby development.

What this means today

We encourage all Heroku developers to use Ruby 1.9.2 for new apps. You can create an app on 1.9.2 with the following command:

$ heroku create --stack bamboo-mri-1.9.2

We also encourage developers to port (or at least test) existing apps on 1.9.2, and to contribute bug reports, feedback, and patches to libraries that aren’t currently 1.9.2-compatible:

$ heroku stack:migrate bamboo-mri-1.9.2

As part of this effort, we have also deprecated the bamboo-mri-1.9.1 stack. Apps that are currently running on it will not be affected, but no new 1.9.1 apps can be created, and you are no longer able to migrate to 1.9.1.

What this means going forward

As of now, bamboo-ree-1.8.7 is still the default stack for new Heroku apps. As support for Ruby 1.9.2 continues to improve, we will regularly review this, with the goal of making 1.9.2 the default in the future. We’ll provide plenty of notice before this switch, of course.

Resources for Ruby 1.9.2

There are a number of great resources for learning about and trying out Ruby 1.9.2. Here are some of our favorites, but feel free to leave yours in the comments!

  • Programming Ruby 1.9 – the latest edition of the book that brought Ruby to the English-speaking world.
  • RVM – we recommend RVM for managing your Rubies in development; it makes testing apps against alternate implementations as painless as possible.
  • Upgrading to Ruby 1.9 – David A Black’s summary of the top 10 things to watch out for when moving from 1.8 to 1.9 – and don’t miss the sequel, which contains even more good information.
  • Is It Ruby 1.9? – a community-powered site for monitoring gem compatibility (and be sure to contribute to it!)

Gemcutter's Adventure on Heroku

Hi there, I’m the creator of a new RubyGem hosting site, Gemcutter. I also happen to be one of the newest hires at Heroku, but I promise, I decided the project was going to be hosted on Heroku long before starting to work here. Heroku’s been kind enough to pitch in getting the site deployed and ready for the whole Ruby community to enjoy.

There’s nothing more fitting than for the next generation of RubyGem hosts to be supported by a truly next generation web application hosting platform. The project has the following goals:

  1. Provide a better API for dealing with gems
  2. Create more transparent and accessible project pages
  3. Enable the community to improve and enhance the site

Recently, the site’s redesign was launched, and we will soon be moving over to http://rubygems.org. Over 23,000 gems are hosted through Amazon S3, and new ones are showing up every day.

Contributors have recently started to add some really neat features such as prerelease gem support and subscribing to RSS feeds for updates about your gems. Some features slated for the near future are full text searching of READMEs for gems, Ruby 1.9 and JRuby compatibility, and allowing gem authors to delete their own gems if they need to.

Gemcutter will be used by default for gem installs when using the Heroku gem manifest starting next week. This should result in faster deploys since the installs will be taking place over the EC2/S3 LAN.

A deeper explanation of how Heroku’s architecture and add-ons has affected Gemcutter’s internal design will be coming soon. The Heroku platform has really helped address some serious issues regarding scalability that wouldn’t have been brought up if we were hosted somewhere else. For now, you can check out how easy it to store files in S3, run background jobs, and use HTTP caching to really speed up your application. And if you haven’t yet, check out gemcutter.org!

Browse the blog archives or subscribe to the full-text feed.