I just upgraded to Rails 2.3.2 but my Ruby is still 1.8.5. Rails 2.3.2
doc says it work fine with 1.8.5 but it recommends 1.8.7. I remembered
from a previous attempt that upgrading Ruby to 1.8.6 was too complicated
for me, so I’m wondering what I would get if I upgrade to 1.8.7 and if I
should just stick with 1.8.5.
There have been a few threads on this so far. Possibly the right
thing to do is to install multiple versions and flip back and forth
if you run into difficulties. Unfortunately, this is complicated and
there are hidden problems. I was laughing about it the other day
with someone because installing Ruby is ironically configuration over
convention.
My own wishful thinking is that Ruby installation becomes more
standardized and that the source comes in a nice friendly repository
that is easy on the disk so I could quickly select, build, and
install different versions in some standard way.
Installing multiple versions is too messy for me. I plan on retiring my
previous code base (written on Rails 1.2.3 / Ruby 1.8.5), so perhaps my
best option is to bite the bullet and do the upgrade?
Juan Z. wrote:
There have been a few threads on this so far. Possibly the right
thing to do is to install multiple versions and flip back and forth
if you run into difficulties. Unfortunately, this is complicated and
there are hidden problems. I was laughing about it the other day
with someone because installing Ruby is ironically configuration over
convention.My own wishful thinking is that Ruby installation becomes more
standardized and that the source comes in a nice friendly repository
that is easy on the disk so I could quickly select, build, and
install different versions in some standard way.
I know some of my libraries are gotta to get whacked but then I might
not use them in my new project. Agreed, it would be great to have
support for multiple Ruby versions though I don’t see that happening
anytime soon.
Juan Z. wrote:
My guess would be that it’s reasonably safe depending on what
libraries you use. I think it would be safer if my wish were
granted. Then library makers would have an easier time testing their
stuff on various systems with various ruby versions.
My guess would be that it’s reasonably safe depending on what
libraries you use. I think it would be safer if my wish were
granted. Then library makers would have an easier time testing their
stuff on various systems with various ruby versions.
Oiy, 1.8.6? To add even more confusion, the Ruby site listed several
versions of 1.8.7, I’m on Windows and not all versions have one-click
installer. Which version is the recommended one to use with Rails 2.3.2?
Anyone knows?
7stud – wrote:
Cali W. wrote:
I know some of my libraries are gotta to get whacked but then I might
not use them in my new project. Agreed, it would be great to have
support for multiple Ruby versions though I don’t see that happening
anytime soon.Juan Z. wrote:
My guess would be that it’s reasonably safe depending on what
libraries you use. I think it would be safer if my wish were
granted. Then library makers would have an easier time testing their
stuff on various systems with various ruby versions.I recently upgraded my ruby, and I chose version 1.8.6. I read a thread
about how 1.8.7 is incompatible the previous 1.8. line, which is going
to cause nightmares with package maintainers who don’t know that. It
has something to do with the version number not indicating so many
changes. After reading that thread, it was either 1.8.6 or 1.9 for me,
and I went with 1.8.6. I don’t ever intend to install 1.8.7.
7stud – wrote:
Corrections:
I read a thread about how 1.8.7 is incompatible the previous 1.8. line
I read a thread about how 1.8.7 is incompatible with the previous 1.8.
line…
Oh, and I also just installed rails 2.3.2.
Cali W. wrote:
Oiy, 1.8.6? To add even more confusion, the Ruby site listed several
versions of 1.8.7, I’m on Windows and not all versions have one-click
installer. Which version is the recommended one to use with Rails 2.3.2?
Anyone knows?
I have the recently published AWDWR(3rd), as in published a couple of
months ago, and it has windows installation instructions. I posted them
for someone else who was looking for directions. Here they are:
From: “7stud --” [email protected]
I recently upgraded my ruby, and I chose version 1.8.6. I read a thread
about how 1.8.7 is incompatible the previous 1.8. line, which is going
to cause nightmares with package maintainers who don’t know that. It
has something to do with the version number not indicating so many
changes. After reading that thread, it was either 1.8.6 or 1.9 for me,
and I went with 1.8.6. I don’t ever intend to install 1.8.7.
I think we have to be careful not to spread FUD about 1.8.7
incompatibilities, though.
The most useful thread for me on this subject has been last
February’s “Re: If you are unhappy with the direction of
Ruby 1.8.7+, respond”.
Particularly interesting was when folks were challenged to
identify specific cases where 1.8.7 truly broke compatibility
with 1.8.6 programs. The silence was deafening.
Here is the summary by Pit C. of how that ended up:
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/328269
On Sun, 15 Feb 2009, Pit C. wrote:
- It is not allowed anymore to create new objects during
garbage collection (the SWIG problem)Both are at least questionable to being categorized as breaking
backwards compatibility and seem to have been fixed. Everything else
that had been said here and in other threads had to be withdrawn.
If that is the case, then it seems apparent we should be very
careful what we mean when we talk about 1.8.7 being
incompatible.
My understanding is that because 1.8.7 incorporates some 1.9.x
features, it allows us to write code which runs in 1.8.7 but which
will not run in 1.8.6. And yes, not everyone is happy with that.
(Including developers of alternate ruby implementations, who
would be looking at more work to maintain separate 1.8.6,
1.8.7, and 1.9.x interpreters.)
But that is different from 1.8.7 breaking 1.8.6 programs. Which
it apparently doesn’t.
Regards,
Bill
Bill, thank you for your detailed response, it’s very helpful in
determining if 1.8.7 is truly incompatible and it surely doesn’t appear
so.
Cali W. wrote:
I know some of my libraries are gotta to get whacked but then I might
not use them in my new project. Agreed, it would be great to have
support for multiple Ruby versions though I don’t see that happening
anytime soon.Juan Z. wrote:
My guess would be that it’s reasonably safe depending on what
libraries you use. I think it would be safer if my wish were
granted. Then library makers would have an easier time testing their
stuff on various systems with various ruby versions.
I recently upgraded my ruby, and I chose version 1.8.6. I read a thread
about how 1.8.7 is incompatible the previous 1.8. line, which is going
to cause nightmares with package maintainers who don’t know that. It
has something to do with the version number not indicating so many
changes. After reading that thread, it was either 1.8.6 or 1.9 for me,
and I went with 1.8.6. I don’t ever intend to install 1.8.7.
7stud – wrote:
Bill K. wrote:
From: “7stud --” [email protected]
My understanding is that because 1.8.7 incorporates some 1.9.x
features, it allows us to write code which runs in 1.8.7 but which
will not run in 1.8.6.But that is different from 1.8.7 breaking 1.8.6 programs. Which
it apparently doesn’t.Hmmm…ok.
So basically 1.8.6 (and prior version) code will work fine in 1.8.7
without changes, but code written using 1.8.7 new features won’t work
with previous versions, did I get that right?
Bill K. wrote:
From: “7stud --” [email protected]
My understanding is that because 1.8.7 incorporates some 1.9.x
features, it allows us to write code which runs in 1.8.7 but which
will not run in 1.8.6.But that is different from 1.8.7 breaking 1.8.6 programs. Which
it apparently doesn’t.
Hmmm…ok.
Cali W. wrote:
So basically 1.8.6 (and prior version) code will work fine in 1.8.7
without changes,
It doesn’t sound like that is the case:
http://www.ruby-forum.com/topic/178354#new
but code written using 1.8.7 new features won’t work
with previous versions, did I get that right?
Obviously.
From: “7stud --” [email protected]
Cali W. wrote:
So basically 1.8.6 (and prior version) code will work fine in 1.8.7
without changes,It doesn’t sound like that is the case:
If you are unhappy with the direction of Ruby 1.8.7+, respond - Ruby - Ruby-Forum
Could you be more specific? It’s a very long thread.
My understanding is that Cali’s statement should be correct.
Code that works on 1.8.6 should work on 1.8.7. (But not
necessarily vice-versa.)
Regards,
Bill
I am using 1.8.7 and it works wonderfully.
Just don’t believe the FUD that a very few vocal people spread here
about how bad and horrible 1.8.7
I see an upgrade to ruby 1.9.x being more difficult, because it gave me
more problems with Encoding stuff so far. The encoding switch alone is a
huge thing, I need to make sure that all my files are “proper” whereas
ruby 1.8.x didn’t care about it.
On Tue, May 5, 2009 at 2:47 AM, Bill K. [email protected] wrote:
If you are unhappy with the direction of Ruby 1.8.7+, respond - Ruby - Ruby-Forum
Could you be more specific? It’s a very long thread.
My understanding is that Cali’s statement should be correct.
Code that works on 1.8.6 should work on 1.8.7. (But not
necessarily vice-versa.)
It’s actually not true in general. There is lots of old 1.8.6 based
code, for example Rails applications running on not-so old versions of
Rails which won’t run on 1.8.7.
If you really go back and read that long thread, I think you’ll find
that while later versions of ruby libraries like Rails have made
changes to accommodate the changes made in 1.8.7, that was
accomplished by changing the code, not by changes to Ruby 1.8.7. So
it’s very likely that, say an old Rails 1.2.x (or even I think a Rails
2.x (for some value of x < the version which was 1.8.7 compatible)
won’t run or won’t run correctly under 1.8.7.
If we’re talking about new code, then yes, 1.8.7 vs. 1.8.6 is at best
a minor issue, but if we are talking about waking up some Rip Van
Winkle application, some assembly will be required. And some ‘ports’
of some Rails applications between Rails versions is a non-trivial
exercise. One company I worked for backed out of migrating its main
app from Rails 2.1 to 2.2 because the rework cost more than it was
worth. Now this is a Rails issue rather than a Ruby issue per se, but
it’s all part of the larger picture.
The real pain of having 1.8.6 and 1.8.7 share the same minor version
number is that downstream ‘vendors’ like the linux packagers see this
as an inconsequential change, they have ONE ruby 1.8 package, and when
they started making this contain 1.8.7 rather than 1.8.6, and owners
of those Rip Van Winkle apps found things broke when they (or their
hosting provider) updated the packaged version of ruby.
That’s why as a result of that thread, the folks at Engine Y. agreed
to continue to maintain a Ruby 1.8.6 version. But it still doesn’t
solve the re-packaging of ‘compatible’ versions for less aware users
and hosting providers.
Rick DeNatale
Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale
So it seems like there are enough chatter on various blogs, etc that
raises some 1.8.7 incompatibility concerns, here’s a specific example on
Rails Forum
http://railsforum.com/viewtopic.php?pid=96484#p96484
Quote: “I wanted to create a hash from an array, so I used:
Hash[my_array] in 1.8.7, which has to be rewritten to Hash[*my_array] in
1.8.6”
Also, it seems like Engineyard has committed to maintain 1.8.6 branch
for the same concern,
http://www.h-online.com/open/Ruby-1-8-6-going-to-the-Engineyard--/news/112685
While I agree that this might not be unique regarding incompatible
upgrades singling out 1.8.7, it does appear there is momentum in the dev
community to stick with 1.8.6 until 1.9 is released. As such, if most
developers use 1.8.6, then there is better overall support for issues,
etc.
Long story short, it seems like 1.8.6 is the way to go for now.
From: “Rick DeNatale” [email protected]
Rails which won’t run on 1.8.7.
If you really go back and read that long thread, I think you’ll find
that while later versions of ruby libraries like Rails have made
changes to accommodate the changes made in 1.8.7, that was
accomplished by changing the code, not by changes to Ruby 1.8.7. So
it’s very likely that, say an old Rails 1.2.x (or even I think a Rails
2.x (for some value of x < the version which was 1.8.7 compatible)
won’t run or won’t run correctly under 1.8.7.
Okay.
Although, if memory serves, there were some similar
issues with Rails and the transition from 1.8.4 →
1.8.6 . . .
Google found, for instance:
http://dlfaquifer.blogspot.com/2008/03/ruby-on-rails-upgrade-woes.html
“I’ve had a terrible experience trying to do a full
stack upgrade of Ruby and Rails (Ruby 1.8.4 → 1.8.6,
Rails 1.1.6 → 1.2.6). Two changes in core Ruby classes
caused problems for me, plus the continued poor support
for MS SQL Server in ActiveRecord continues to plague
me. It may have put me off upgrading my RoR apps. any
more.”
In which case, it may not be entirely fair to single out
1.8.7 in this regard?
Regards,
Bill
It might not be that hard to suck every version of the Ruby source
into git. Then they could all be downloaded efficiently all at
once. After that a ruby script could build several of the key stable
versions, install them, and then install another script called
something like rubyswitch. Running rubyswitch would change
the currently active version by changing the path. Then the test
cycle would be faster and falling back would be trivial.