[ruby-core:22000] Re: 1.8.7 Specifics

On Wed, Feb 11, 2009 at 1:42 PM, John Barnette <[e-mail]> 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