From: Gregory Brown Date: 2009-02-12T04:01:58+09:00 Subject: [ruby-core:22000] Re: 1.8.7 Specifics On Wed, Feb 11, 2009 at 1:42 PM, John Barnette wrote: > There's a fair amount of talk lately about release management and > version stability, most of it stemming from the way the release of > Ruby 1.8.7 was handled. Despite all the talk, I haven't seen a good > list of problems with 1.8.7 that's not buried in a fair amount of > hyperbole. I'd appreciate it you'd reply to this thread with specific > problems you've encountered in 1.8.7, especially problems that have > kept you from upgrading. > > Let's try to avoid the philosophical disagreements around backporting > new features, etc, and stick to specific bugs and technical problems, > okay? There are plenty of other threads that cover all that. :) When I initially tried running Ruport's tests on 1.8.7, there were some failures. I don't remember the specifics, so that probably only half counts. As a project maintainer, I wish to maintain 1.8.6 compatibility in my projects (Prawn, Ruport, etc). I am already supporting Ruby 1.9 as well in Prawn and will do so in Ruport. But to support 1.8.7+, I'd need to add a third branch to that already ugly version-selection logic. Without that, when a patch is submitted to me that depends on a Ruby 1.8.7 feature, it might slip through the cracks and break my 1.8.6 compatibility. I really do not want to run tests on 1.8.6, 1.8.7 *and* 1.9.1 each time, even if there are tools out there that make this easier. It seems there are only two alternatives that make maintainability easier: Drop 1.8.6 support and force the users of my packages to upgrade to Ruby 1.8.7 and then eventually Ruby 1.8.8 and keep doing that whenever ruby-core decides they want to redefine Ruby 1.8's API, or focus on supporting *only* Ruby 1.9. I really hope that Matz and friends aren't planning on using this terrible version scheme there, because then I'll just be forced to deal with it no matter what. So for me, whether or not the releases are backwards compatible doesn't matter. It's that they aren't API-frozen, because this becomes a big problem for folks who are maintaining code that has many contributors running on different version of Ruby and thousands or tens-of-thousands of users in the same position. If I wasn't producing software for wide distribution, maybe this issue wouldn't concern me. If I could experiment with Ruby itself all day rather than manage projects that use it, maybe this issue wouldn't concern me. But I'm not in those shoes, so it does. -greg -- Technical Blaag at: http://blog.majesticseacreature.com Non-tech stuff at: http://metametta.blogspot.com "Ruby Best Practices" Book now in O'Reilly Roughcuts: http://rubybestpractices.com