Multiple Ruby Patchlevels and Bundler Versions

Fine-grained dependency control is essential to a keeping yourself sane as a developer.  A coarse example is when you are writing code on OSX and your teammate is coding on Linux.  Your teammate complains to you that some of the tests fail, but they all pass for you.  You spend several hours debugging and realize that the order of files returned by the filesystem is different.

Now, let’s consider the Ruby development environment.  The three ubiquitous fixtures in modern Ruby applications nowadays are:

  1. Ruby (of course!) including rubygems
  2. Bundler (and a Gemfile)
  3. rake (and a Rakefile)

RVM, rbenv, and other tools (bundler 1.2.0.pre) have sprung into existence to manage the wide array of Ruby implementations and versions. Bundler, of course, itself arose to manage the wide array of gem dependencies that make ruby such a great environment to work in.  Usually, the Gemfile lists a version of rake.

One of bundler’s advantages is the ability to ensure that fine-grained dependency versions don’t change (as in Gemfile.lock).  The devil, as they say, is in the details:  minor version changes in gems can come with significant changes in functionality.  The same holds true for Ruby versions, and unfortunately even for ruby patchlevels.  For example, ruby-1.9.2-p320 isn’t fully compatible with ruby-1.9.2-p290, at least not when it comes to constant namespacing.

The issue also applies to bundler itself.  Even with a tool like RVM, changes in bundler need to be manually tracked, at least for basic app bootstrap – bundler can’t install itself.  Thanks to all of the folks working so hard on bundler, it’s seen some change over the past few months.  While many developers keep up with all of the changes, some are working in environments where they can’t (or simply don’t have the time) and they’ve come to rely on the quirks of the version they started with.

Ruby Patchlevels

We already support Ruby 1.8.7, 1.9.2, 1.9.3, and REE, but we had only been supporting a single patchlevel for each of them.  We upgraded some of our users from 1.9.2-p290 to 1.9.2-p320, and quickly realized that it caused some trouble with factory_girl.  While many of our users depend on 1.9.2-p290, some had come to depend on p320.

Well, I’m happy to say that we’ve recently rolled out support for multiple patchlevels of a given Ruby release, and we’ll institute a phased lifetime policy where we’ll gradually end-of-life older patches.

We currently support:

  • ree-1.8.7-2011.03
  • mri-1.8.7-p352
  • mri-1.9.2-p290 and -p320
  • mri-1.9.3-p194

You can request additional patchlevels to be supported by emailing us at support@tddium.com. We should have them available within a day or two.

You can explicitly set the ruby version for a Tddium suite by updating to tddium-1.4.4 and running:

[sourcecode lang=”shell”]
$ tddium suite –edit –tool=ruby_version:ruby-1.9.2-p290
[/sourcecode]

Bundler Versions

The “tddium run” and “tddium suite” commands will now honor the exact bundler version they detect in your environment.

You can also use the “tddium suite” command to set it:

[sourcecode lang=”shell”]
$ tddium suite –edit –tool=bundler_version:1.2.0.pre
[/sourcecode]

Enjoy!

We intend these changes to make Tddium more closely conform with your development environment.  Stay tuned for more updates, and as always, don’t hesitate to email us with questions, comments, or suggestions.

– The Tddium Team

Post a Comment