On Wed, Feb 11, 2009 at 6:28 PM, Aaron Patterson
<aaron / tenderlovemaking.com> wrote:
> On Thu, Feb 12, 2009 at 04:01:58AM +0900, Gregory Brown wrote:
>> On Wed, Feb 11, 2009 at 1:42 PM, John Barnette <jbarnette / gmail.com> wrote:

>> As a project maintainer, I wish to maintain 1.8.6 compatibility in my
>> projects (Prawn, Ruport, etc).  I am already supporting Ruby 1.9 as
>> well in Prawn and will do so in Ruport.  But to support 1.8.7+, I'd
>> need to add a third branch to that already ugly version-selection
>> logic.  Without that, when  a patch is submitted to me that depends on
>> a Ruby 1.8.7 feature, it might slip through the cracks and break my
>> 1.8.6 compatibility.  I really do not want to run tests on 1.8.6,
>> 1.8.7 *and* 1.9.1 each time, even if there are tools out there that
>> make this easier.

> I can't agree with this at all.  If you refuse to run your tests
> against any particular version of ruby, how can you say you support
> that version?

I don't support 1.8.7.  The issue is that people can fairly easily
accidentally write code that does not run on 1.8.6.  This hasn't been
the case in my experience as a package manager all the way back to
1.8.4.   I used to think basically that 1.8 was 1.8, and though some
things shifted around to fix problems, and occasionally something went
wrong (like YAML in 1.8.3) that  I didn't need to learn new features
from version to version, or ask my users to bump their ruby to a
certain supported version.  This is new to me.

> To bring this thread back on topic; what code, specifically, are you using
> that needs to be different for 1.8.6, 1.8.7, and 1.9?

The issue is that 1.9.1 isn't backwards compatible with 1.8.7.  So,
code I write on Ruby 1.9.1 doesn't necessarily work on 1.8.7.   But
now I switch branches and get things working.  But then code I write
there doesn't work on 1.8.6.  So I need to write a 1.8.6 version too.
 But because 1.8.7 *is* mostly backwards compatible, I don't actually
need that 1.8.7 code.  So what, exactly, is 1.8.7 doing for me, in a
situation where I support both Ruby 1.8 and 1.9?

In all honesty, I'd be fine with the core team announcing an end of
life of Ruby 1.8 as a whole.  That'd free up resources and end
confusion.   Has this possibility been considered?

-greg

-- 
Technical Blaag at: http://blog.majesticseacreature.com
 Non-tech stuff at: http://metametta.blogspot.com
"Ruby Best Practices"  Book now in O'Reilly Roughcuts:
http://rubybestpractices.com