From: enos76 on
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

--
Enos
From: Jonathan Nielsen on
On Wed, May 5, 2010 at 9:05 AM, enos76 <enos76(a)gmail.com> wrote:
> 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
>
> --
> 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(tm) :)

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 Nielsen

From: enos76 on
Jonathan Nielsen 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
--
Enos
From: Kevin Hopkins on
[Note: parts of this message were removed to make it a legal post.]

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

On Wed, May 5, 2010 at 11:05 AM, enos76 <enos76(a)gmail.com> wrote:

> 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
>
> --
> Enos
>
>


--
Kevin Hopkins, MCP MCTS
(c) 540.331.1772
(e) kevin(a)wearefound.com
(w) www.wearefound.com

From: Kevin Hopkins on
[Note: parts of this message were removed to make it a legal post.]

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

On Wed, May 5, 2010 at 11:30 AM, enos76 <enos76(a)gmail.com> wrote:

> Jonathan Nielsen 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
> --
> Enos
>
>


--
Kevin Hopkins, MCP MCTS
(c) 540.331.1772
(e) kevin(a)wearefound.com
(w) www.wearefound.com