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 =20
the standard libraries and for commonly used Gems.

The libraries are a minor issue, but still an annoying one. It is =20
disturbing that Ruby 1.9 was supposed to have been relatively stable =20
for over 6 months now, and yet we still have libraries that are =20
supplied with the standard distribution that are broken. =46rom the end-=20=

users perspective, these libraries are as much part of Ruby as is the =20=

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 =20
broken by 1.9. Changes to encoding, string indexing, and the like have =20=

caused all kinds of errors, both big and subtle. I'd guess that =20
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 =20
disturbing, particularly as there's no indication until I try to use a =20=

Gem whether or not it works. And once a user finds a couple of Gems =20
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 =20=

adoption of 1.9. And if we don't see widespread adoption, I question =20
the point of releasing it at all.

So, along with the release plans for the interpreter itself, I think =20
I'd like to see two other things happen:

1. Change the RubyGems built into 1.9 so that it defaults =20
required_ruby_version to '< 1.9'. That way, any gem that doesn't =20
explicitly set required_ruby_version will automatically not run on =20
1.9. This will act as an obvious indicator to both users and the gem's =20=

maintainer that something needs to be done before the Gem is =20
acknowledged to be compatible with 1.9. It will also allow us to do =20
queries on RubyForge to track the progress of the 1.9 migration. With =20=

many gems, no change will be required apart from an update to the =20
gemspec. But forcing the maintainer to make that update means that the =20=

gem is explicitly listed as being 1.9 compatible.

2. As a parallel activity, I think we need to make Gem maintainers =20
aware of the need to make their Gems compatible. We have contact =20
details in RubyForge=97starting a maintainers' wiki, and emailing all =20=

maintainers with details, will be a good start.

I love the features in 1.9. I seems a shame not to have people use =20
it.  Let's put some effort into making the whole package, and not just =20=

the interpreter, ready for widespread adoption.



Dave