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