I have a site running older versions of Ruby and Rails. It’s running
Ruby 1.8.4 and Rails 1.2.2.

It’s working fine, but I’ve set up a new desktop and now I need a
development environment for it.

I look at the latest version of Ruby and Rails and it’s not
compatible, so I’m left with two choices.

Match the ruby and rails in production for now, while I plan for an
upgrade. The only problem here is that I can’t seem to find older
releases of ruby on the ruby website, and the online documentation
doesn’t seem to track anything but the latest versions anyway.

Upgrade production to the latest, but I’m unsure of the best
procedure to do this. Right now the current boot.rb and environment.rb
files are not even compatible so I’m assuming that I’d start there.

So, what is the recommended upgrade procedure, and where do I find
older copies of Ruby? I’m assuming that I can still find older copies
of rails by specifying the version to gem install.

I have a site running older versions of Ruby and Rails. It’s running
Ruby 1.8.4 and Rails 1.2.2.

It’s working fine, but I’ve set up a new desktop and now I need a
development environment for it.

To add to the good advice you already got – I would seriously think
about creating a virtualized environment to replicate production’s
ruby/rails/gems setup rather than changing your desktop system’s
base install.

You might even create other VMs for the intermediate steps of the
upgrade – no unexpected conflicts, disposable when finished.

Oh, and Rails 3 is secretly gonna be Merb configured to look like Rails.
Joy. If
too few established rails sites use it (like >100,000 users), then maybe
Rails 2
will never go out of maintenance, despite my blog entry!

If I were on my own notebook, I would just pick one of those header
files and
edit it.

The point is C++ “recently” (meaning “recently” in glacial C++ time)
became more
restrictive around pointer types. Foo * cannot silently cast to Foo
const *
anymore, despite the latter is more restrictive. So one function
prototype
cannot match the other.

But the linker can’t see these details, so if you just tweak the
headers, the
compiler was the last chance to catch this non-error, and if you thwart
it, you
will have your executables.

I Just wish all the Rails books I read mentioned how difficult this
kind of thing can be. They always make working with these new
frameworks look so attractive without mentioning that if you don’t
move forward in production quickly enough then you’ll find yourself
left behind.

Oh, and Rails 3 is secretly gonna be Merb configured to look like Rails. Joy. If
too few established rails sites use it (like >100,000 users), then maybe Rails 2
will never go out of maintenance, despite my blog entry!