On Thu, Feb 12, 2009 at 2:33 PM, Pit Capitain <pit.capitain / gmail.com> wrote:
> 2009/2/12 Gregory Brown <gregory.t.brown / gmail.com>:
>> On Thu, Feb 12, 2009 at 1:59 PM, Pit Capitain <pit.capitain / gmail.com> wrote:
>>> Gregory, there is no Ruby 1.8 and has never been. There have been
>>> 1.8.0, 1.8.1, up to 1.8.7, each one differing from the others.
>>
>> You keep saying this but frankly, it's ridiculous.  Yes, you can find
>> changes.  In Ruby 1.8.7, you get clubbed over the head with them.
>
> So we agree to disagree. Though I'd be interested in what you'd define
> as "Ruby 1.8". Is it 1.8.6? Why not 1.8.2? Does 1.8.5 qualify as being
> a "Ruby 1.8", despite the differences to 1.8.6? In the end I'm sure it
> will be 1.8.6, so why not name it as such? Why interpret more into it
> as it really is?

I understand what you mean here, and actually, you're right in saying
that the term "Ruby 1.8" is completely amorphous.

But I suppose what I'm saying is that from 1.8.2 up until 1.8.6, I did
not once say "Wow! now I can do all this new cool stuff!".   I also
didn't worry too much about whether code I wrote on my latest Ruby 1.8
version would work in various out of date production environments.  I
did not worry about patches from contributors having the same problem
in my open source projects.

The situation also might be different for me if 1.9 didn't exist.  But
I'm not sure you'll agree with my reasoning on that, and it's not
terribly important anyway, so I won't elaborate further.

>> We're not in disagreement here.  It's just been my experience that I
>> can write code on 1.8.6 without thinking about back-wards
>> compatibility with earlier versions, for the most part.  We all know
>> that things have changed, but not in so radical a fashion.
>
> Hmm, let's see how radical a change 1.8.7 has been until now:
> Hash#hash has been changed (or should I say: fixed), it's not allowed
> to allocate new objects during garbage collection anymore (the SWIG
> problem), plus (admittedly a large number of) new features have been
> added. I wouldn't call this radical, but, again, we just disagree
> here, so I'll shut up now.

I think you're looking at this from the perspective of standalone Ruby
code, and I can see a bit of what you're saying from that perspective.
 But I'm speaking based on my experience of having to deploy code to
older versions of Ruby in a commercial setting, as well as running
several mainstream open source projects that have an active
contributor base.   It is possible that we're 'both right' in our own
situations, and that this solution of having EY run 1.8.6 might give
us the best of both worlds.

I apologize for using vague terminology about '1.8', it's probably the
main source of dispute here.

-greg