polishing ruby by ryan davis

RubyGems How-To: Preventing Catastrophe

Published 2008-10-01 @ 13:47

Tagged ruby

I’m about to put out a flood of releases, several of which are “dot-ohs” and are not fully backwards compatible. In doing so, I knew that projects dependent on my projects (including some of my own) might break. Here is how to avoid that scenario.

Here is ParseTree’s dependencies and dependents:

  ParseTree:
    dependencies:
      RubyInline-3.7.0          >= 3.6.0
      hoe-1.7.0                 >= 1.5.3
    dependents:
      RubyToC-1.0.0.5            > 0.0.0
      SuperCaller-1.0.0         ~> 2.0
      ZenHacks-1.0.1             > 0.0.0
      ambition-0.5.2             = 2.0.1
      argible-0.1.1             >= 2.0.0
      flog-1.1.0                >= 2.0.0
      merb-action-args-0.9.7    >= 2.2
      protocol-0.8.0            >= 2.0.2
      red-3.5.0                 >= 2.2.0
      reek-0.2.3                >= 2.2.0
      rogue_parser-1.0.1        >= 0
      roodi-1.3.0               >= 0
      ruby2ruby-1.1.9           >= 0
      ruby_diff-0.1.5           >= 2.0.2
      ruby_parser-1.0.0         >= 0
      rubyjs-0.8.0              >= 2.1.1
      sake-1.0.15                = 2.1.1
      scrubyt-0.3.4              = 1.7.1
      thorero-action-args-0.9.4 >= 2.2

Now, let’s say I put out RubyInline 4.0.0 and it isn’t fully backwards compatible with RubyInline 3.x.y. What happens? Well, anyone installing ParseTree or otherwise updating their gems will update RubyInline and their ParseTree will break. Why? Because the version specifier for RubyInline is “>=” and 4.0.0 is just fine with that.

What I should have done was specify “~> 3.0”. That lets me flexibly set a range of dependencies but does not go up to the next major release. By extension, every single dependency on ParseTree listed above is going to break except SuperCaller.

Here is how the dependency specifiers work:

Version Specification
3 and up, ”>= 3”
3.y.z, ”~> 3.0”
3.0.z, ”~> 3.0.0”
3.5.z to <4.0 ”~> 3.5”
3.5.z to <3.6 ”~> 3.5.0”

So, armed with that, make sure that from here on out you specify your dependencies with “~>” and catastrophe won’t visit your doorstep.

P.S. I’m about to directly email all the authors of projects dependent on my upcoming releases to warn them… Hopefully we can mop all this up quickly.