Akinori MUSHA wrote:

> Here is an announcement that the second preview of Ruby 1.8.7 has just
> been released. 

...

> The new version of Ruby includes many bug fixes, lots of feature
> enhancements 

...


> 	http://svn.ruby-lang.org/repos/ruby/tags/v1_8_7_preview2/NEWS
> 	http://svn.ruby-lang.org/repos/ruby/tags/v1_8_7_preview2/ChangeLog

Firstly, Akinori, thank you very much for your generous work on ruby. 
The criticisms that follow are not at all directed at your work, but 
rather at what seems a casual and ill-advised approach to branch 
management in Ruby.

Even though this may well be a good release, it isn't a stable 
development of the 1.8 series, but a hybrid of 1.8 with a random 
selection of 1.9 features added in (many or most of which I like, in 
their own right). But if I can't use 1.8.7 without unwittingly writing 
code that's incompatible with every other released version of ruby, then 
it's not a stable release.

This isn't just a hypothetical problem. The lax approach to stable 
branch management has bitten me twice in the last 24 hours. I was using 
Digest for the first time in a while; I couldn't remember exactly how 
the module works, but using 1.8.6, I soon come up with:

require 'digest'
foo = Digest::SHA1(some_string)

Which works fine. Except, I realise today looking at the NEWS file, that 
I've just written code which will break on every previous ruby version. 
Did I want that? No - but how could I tell, except if I'd memorised 
Ruby's CHANGELOG?

More seriously, I just tried out 1.8.7-preview2 with a large compiled 
extension (wxRuby). What was a stable library in 1.8.6 now segfaults 
regularly. Debugging GC/memory problems in a ruby extension is a 
miserable job, but doubly so if you're chasing a moving target in a 
supposedly stable series. Right now, I can't see any point in trying to 
support 1.8.7.

Many or most open-source projects are strict about maintaining 
compatibility within stable release series, and I don't understand why 
ruby can't be. I think the desire to extend and improve the language is 
great, but in the shorter term ruby provides many ways to test, use and 
refine enhancements (facets, ActiveSupport) while maintaining some sense 
of dependability in the core interpreter. I like Array#index { ... } but 
I can live without it a few months longer.

Anyway, some of this reiterates what's been said elsewhere by others 
[1]. It's been suggested in reply that only mission-critical application 
developers and rigid corporate types care about stability within branches.

In fact, this sort of casual branch management imposes a cost borne by 
ordinary users (who find libraries randomly don't work with the version 
of ruby they happen to have installed) and average library developers 
(who can't be sure that they are targetting more than a single 
point-version, and end up fielding more support requests).

But, I guess that since there's a world shortage of new Integers between 
8 and 9, there's no hope that this release could be given a more 
appropriate version tag?

alex

[1] http://www.ruby-forum.com/topic/149772#new