[ruby-core:17658] Re: Features to be included in Ruby 1.9.1

Dave Thomas wrote:
> 
> On Jul 7, 2008, at 9:59 PM, Yugui (Yuki Sonoda) wrote:
> 
>>
>> Committers and anyone who intend to write patches, let me know your
>> plan. What features will be implemented by 25 Sep? What will not?
> 
> My biggest concern is not for the core interpreter, but instead for the 
> standard libraries and for commonly used Gems.
> 
> The libraries are a minor issue, but still an annoying one. It is 
> disturbing that Ruby 1.9 was supposed to have been relatively stable for 
> over 6 months now, and yet we still have libraries that are supplied 
> with the standard distribution that are broken. From the end-users 
> perspective, these libraries are as much part of Ruby as is the String 
> class, and it reduces confidence to find some don't work.
> 
> But a bigger issue is the state of Gems. A whole bunch of Gems are 
> broken by 1.9. Changes to encoding, string indexing, and the like have 
> caused all kinds of errors, both big and subtle. I'd guess that perhaps 
> 50% of the Gems out there just plain don't work under 1.9.
> 
> Again, looking at it from an end user's point of view, it's disturbing, 
> particularly as there's no indication until I try to use a Gem whether 
> or not it works. And once a user finds a couple of Gems they rely on are 
> broken by 1.9, they just won't switch.
> 
> Until this situation is addressed, I don't think we'll see widespread 
> adoption of 1.9. And if we don't see widespread adoption, I question the 
> point of releasing it at all.
> 
> So, along with the release plans for the interpreter itself, I think I'd 
> like to see two other things happen:
> 
> 1. Change the RubyGems built into 1.9 so that it defaults 
> required_ruby_version to '< 1.9'. That way, any gem that doesn't 
> explicitly set required_ruby_version will automatically not run on 1.9. 
> This will act as an obvious indicator to both users and the gem's 
> maintainer that something needs to be done before the Gem is 
> acknowledged to be compatible with 1.9. It will also allow us to do 
> queries on RubyForge to track the progress of the 1.9 migration. With 
> many gems, no change will be required apart from an update to the 
> gemspec. But forcing the maintainer to make that update means that the 
> gem is explicitly listed as being 1.9 compatible.

That sounds like a great idea.

> 2. As a parallel activity, I think we need to make Gem maintainers aware 
> of the need to make their Gems compatible. We have contact details in 
> RubyForge耀tarting a maintainers' wiki, and emailing all maintainers 
> with details, will be a good start.

A few months back, I started a modest effort to get a few gems with next 
to no dependencies to work on the latest Ruby 1.9.

http://intertwingly.net/projects/ruby19/logs/

Everything on that page had passed at one time, though most with 
workarounds:

http://intertwingly.net/projects/ruby19/logs/_issues.html

In each case, I attempted to contact the author of the gem, often 
multiple times.  In one case, the blocking issue is something that I 
brought up on this list and raised an issue - a change in behavior from 
Ruby 1.8.6 on the following:

http://rubyforge.org/tracker/index.php?func=detail&aid=17700&group_id=426&atid=1698

I plan to discuss this at OSCON, and hopefully can find some volunteers 
to help.

http://en.oreilly.com/oscon2008/public/schedule/detail/2969

> I love the features in 1.9. I seems a shame not to have people use it.  
> Let's put some effort into making the whole package, and not just the 
> interpreter, ready for widespread adoption.
> 
> Dave

- Sam Ruby