At Elevator Up we typically use Capistrano for deploying our applications. Though I do have a bookmark to investigate Vlad when I get some time.

We've been a bit slow to upgrade to Capistrano 2.x, and have a lot of existing applications that depend upon Capistrano 1.4 for deployment.

One tactic we've taken is to write a custom script to explicitly use 1.4 in conjunction with 2.x. A minor hack from the original, and we have:

#!/usr/bin/env ruby

begin
  require 'rubygems'
  gem 'capistrano', '<= 1.4.1'
rescue LoadError
  # no rubygems to load, so we fail silently
end

require 'capistrano/cli'

Capistrano::CLI.execute!

I threw this into a script called cap1.4 in /usr/local and can now do:

illian:~ zach$ cap1.4 -V
Capistrano v1.4.1
illian:~ zach$ cap -V
Capistrano v2.1.0

Obviously, a better approach would be to freeze in the capistrano gems per project, and access them via RAILS_ROOT/script/cap, but that too has been time sensitive. Notice a trend here?

2 Responses to “Using Capistrano 1.4 with 2.x”

  1. Marcus Derencius Says:

    ruby gems already come with a solution for this problem. Just add RELEASE on command line. E.g.:

    cap 1.4.1 -V # Capistrano v1.4.1 cap -V # Capistrano v2.4.0 rails 2.0.2 -v # Rails 2.0.2 rails -v # Rails 2.1.0

  2. Zach Moazeni Says:

    Marcus,

    Thanks for the tip. Ironically another developer showed me this 2 weeks ago. I just forgot to update this post. However at the time I thought it was a Capistrano only facility, not gems. Pretty cool.

    Here’s the usage with better formatting:

    
    
    # For Capistrano 1.4.1
    cap _1.4.1_ -V
    
    # Rails 2.0.2
    rails _2.0.2_ -v
    
    # Rails 2.1.0
    rails _2.1.0_ -v
    
    

Sorry, comments are closed for this article.