On Tue, Jul 08, 2008 at 11:49:37PM +0900, Sam Ruby wrote:
> 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.
>>
>>
>> 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?starting 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.
>
It could be good idea propagate 1.8 backward compatiblity script more.
It is better have one code for both 1.8 and 1.9 then two versions