From: Martin Duerst Date: 2007-12-28T14:04:03+09:00 Subject: Re: Legacy support (Was: Base64 not there makes Rails 2.0.2 fail toload in 1.9.0) At 00:25 07/12/28, Charles Oliver Nutter wrote: >Richard Kilmer wrote: >> I think it would be good to warn in 1.9 if the gem DOES NOT have the required_ruby_version set (which most won't btw). Warn that this gem may not be compatible with Ruby 1.9. It would also be helpful to have this message at gem install time. This is an annoyance, and like Dave said, it will pressure people to update them, but at least we will then know what gems are explicitly ready for 1.9. > >I raised this question on the RubyGems list and didn't get the answer I hoped...so I reraise it here: > >How should one create a gem that works on both 1.8 and 1.9 given such major changes as String M17N? For M17N, it really depends on what you are doing. Many things are easy, such as checking for String#each and adding it back in if not available (alias it to String#each_line), or better yet, change your code to use each_line and alias the other way round so that your code is moving ahead. If your strings uses non-ASCII characters, use both $KCODE (or the corresponding option) as well as the first/second line comment hack. If you work with multiple encodings, for the moment, stay with Iconv or Kconv/NKF for transcoding unless you know you only need the very limited number of encodings currently supported by String#encoding (and tell me what other encodings you want supported, so that I can add them :-). In principle, if you get encoding errors on 1.9, then that should mean that: - You made a mistake that wasn't detected until now - You cut some corners, you have to do that more explicitly in 1.9 - You found a bug, please tell us here and it should be fixed soon. If you work with character semantics, then the chances are that your program will work with more encodings/languages/scripts in 1.9 than it did in 1.8. If you work with raw bytes, however, you will have to be a bit more explicit for 1.9. The above is a very, very rough overview. If you have a specific I18N/M17N problem, just mention it here on the list. While I think the current M17N architecture should be solid, I'm sure there are a few rough corners that we can only find out about by actual widespread use by people who don't know the internal details. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp