Some time ago I started experimenting with Ruby on Rails.
I stopped almost immediately, because after updating gems or Rails
itself, I often ended up with non-working applications.
I was not the only one with such problems.
Recently I also saw a conference by the founder of Rails, who stated
that
revolutionary ideas that could brake old applications could have been
considered for Rails 3.
How do professional Rails developers cope with such issues?
Thanks,
Regards
On Wed, May 5, 2010 at 9:05 AM, enos76 [email protected] wrote:
Thanks,
Regards
–
Enos
This is a question you will probably want to ask the Rails mailing
list instead of the Ruby mailing list, Ruby is not Rails™ 
However, this problem has not been my experience working with Rails 2.
Gem updates and Rails updates have rarely broken my apps, and the few
code changes I have needed have been well-documented.
-Jonathan N.
Jonathan N. wrote:
[…] Gem updates and Rails updates have rarely broken my apps, and the
few code changes I have needed have been well-documented.
Let’s say you must reinstall a server, or migrate many old applications
into a single machine. In such case, could it be that you would have to
fix their code?
(last question then I migrate to the Rails mailing list I promise :-P)
Thanks, bye
I know this more of a Rails specific question but I’ll answer it
anyways.
Typically in our development environment, we choose a set of
gems/plugins
and ruby/rails version to stick with, in our case its Ruby 1.8.7 with
Rails
2.3.5. When we choose our gems/plugins, we always pay attention to the
versions and stick with it.
In your environment.rb file in the config directory, when we require the
gem
in particular, we also set the params to include the version number and
sometimes the source. this needs t obe done because certain gems have
dependencies and though one gem is updated, the dependency may or may
not
be. i.e. in a recent application I used the gem httparty version 0.4.3
and
bitly version 0.4.0 which both have a dependency on the gem crack
version
0.1.1. when i installed another gem, it installed crack 0.1.4 which was
getting called instead of 0.1.1 and broke httparty and bitly which broke
the
app. These are difficult things to bridge the gap on and I ended up
dumping
the newer gem that I was using and finding a different means.
With having the community create and publish all these gems and plugins,
you
really have to analyze the dependencies and chances are when you run a
sudo
gem update, it will break your app and youll have to find a different
way to
cope. As a developer, finding a design pattern for setting up your
environment is a necessity as well as being strictly specific in your
environment.rb
example:
Rails::Initializer.run do |config|
config.gem “rack”, :version => ‘1.0.1’
config.gem “rack-oauth”
require “rack-oauth”
config.middleware.use Rack::OAuth, :site => “http://twitter.com”, :key
=>
$TWITTER_TOKEN, :secret => $TWITTER_SECRET, :redirect =>
“/twitter_auth/complete”
config.gem “hashie”, :version => ‘0.1.3’
config.gem “crack”, :version => ‘0.1.1’
config.gem “aws-s3”, :version => ‘0.6.2’, :lib => “aws/s3”
end
Hope this helps,
_Kevin
Kevin Hopkins wrote:
[…] In your environment.rb file in the config directory, when we
require the gem in particular, we also set the params to include the
version number and sometimes the source […]
[…] when you set it up explicitly, you will be requiring the certain
versions and libraries. When you need to migrate the app, boom, run
rake gems:install […]
If your inheriting a project and have access to the previous server,
just run gem list and make a notation of the versions of the gems
installed. Then yo ucan run through the environment file […]
Exactly what I needed to know. Now after doing a little research on gem
version coexistence I will be ready to go.
Many thanks.
Bye,
To answer this question, check out my previous email about the
environment.rb config. when you set it up explicitly, you will be
requiring
the certain versions and libraries. When you need to migrate the app,
boom,
run rake gems:install or rake gems:unpack and it will either download
and
install or simply unpack from vendor the correct version of the gems you
need.
If your inheriting a project and have access to the previous server,
just
run gem list and make a notation of the versions of the gems installed.
Then yo ucan run through the environment file in that project and update
the
code to reflect the gems that were being used to simplify
migrations/deployments in the future.
Hope this helps,
_Kevin