Upgrading Spree with the help of Git
By Steph Skardal
June 28, 2010
Lately, I’ve upgraded a few Spree projects with the recent Spree releases. Spree is a Ruby on Rails ecommerce platform that End Point previously sponsored and continues to support. In all cases, my Spree project was running from the Spree gem (version 0.10.2) and I was upgrading to Spree 0.11.0. I wanted to go through a brief explanation on how I went about upgrading my projects.
First, I made sure my application was running and committed all recent changes to have a clean branch. I follow the development principles outlined here that describe methodology for developing custom functionality on top of the Spree framework core. All of my custom functionality lives in the RAILS_ROOT/vendor/extensions/site/ directory, so that directory probably won’t be touched during the upgrade.
steph@The-Laptop:/var/www/ep/myproject$ git status # On branch master nothing to commit (working directory clean)
Then, I tried the rake spree:upgrade task with the following results. I haven’t upgraded Spree recently, and I vaguely remembered there being an upgrade task.
steph@The-Laptop:/var/www/ep/myproject$ rake spree:upgrade (in /var/www/ep/myproject) [find_by_param error] database not available? This task has been deprecated. Run 'spree --update' command using the newest gem instead.
OK. The upgrade task has been removed. So, I try spree –update:
Updating to Spree 0.11.0 ... Finished.
That was easy! I run ‘git status’ and saw that there were several modified config/ files, and a few new config/ files:
# On branch master # Changed but not updated: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: config/boot.rb # modified: config/environment.rb # modified: config/environments/production.rb # modified: config/environments/staging.rb # modified: config/environments/test.rb # modified: config/initializers/locales.rb # modified: config/initializers/new_rails_defaults.rb # modified: config/initializers/spree.rb # # Untracked files: # (use "git add <file>..." to include in what will be committed) # # config/boot.rb~ # config/environment.rb~ # config/environments/cucumber.rb # config/environments/production.rb~ # config/environments/staging.rb~ # config/environments/test.rb~ # config/initializers/cookie_verification_secret.rb # config/initializers/locales.rb~ # config/initializers/new_rails_defaults.rb~ # config/initializers/spree.rb~ # config/initializers/touch.rb # config/initializers/workarounds_for_ruby19.rb </file></file></file>
Because I had a clean master branch before the upgrade, I can easily examine the code changes for this upgrade from Spree 0.10.2 to Spree 0.11.0:
- load_rails("2.3.5") # note: spree requires this specific version of rails (change at your own risk) + load_rails("2.3.8") # note: spree requires this specific version of rails (change at your own risk)
- config.gem 'authlogic', :version => '>=2.1.2' + config.gem 'authlogic', :version => '2.1.3' - config.gem 'will_paginate', :lib => 'will_paginate', :version => '2.3.11' + config.gem 'will_paginate', :lib => 'will_paginate', :version => '2.3.14' - config.i18n.default_locale = :'en-US' + config.i18n.default_locale = :'en'
-config.gem 'test-unit', :lib => 'test/unit', :version => '~>2.0.5' if RUBY_VERSION.to_f >= 1.9 +config.gem 'test-unit', :lib => 'test/unit', :version => '~>2.0.9' if RUBY_VERSION.to_f >= 1.9
Most of the changes were not surprising, except that the locale changes here are significant because they may require extension locales to be updated. After I reviewed these changes, I installed newer gem dependencies and bootstrapped the data since all my application data was stored in sample data files and restarted the server to test the upgrade. Then, I added the config/ and public/ files in a single git commit. I removed the old temporary configuration files that were left around from the upgrade.
For this particular upgrade, my git log shows changes in the files below. The config/ files were made when I ran the update, and the public/ files were modified when I restarted the server as gem public/ files are copied over during a restart.