[ruby-core:21975] Re: New hash : syntax for the 1.8 series?

Charles Oliver Nutter wrote:
> I hope there's some consideration for alternative implementations as
> well. If you were us, what would you do? Support only 1.9.1 features?
> Move to 1.8.7? Support 1.8.6, 1.8.7, and 1.9.1? And then add 1.8.8 on
> top of that?

I, as one of a mentor of "alternative implementations" than matz's 1.9, know so
well how painful it is to chase moving targets.  We really need a steady point
of implementation to refer.  To be honest I personally wish 1.8 should have
been more solid, conservative in changes than it is now.

But that was not what we chose.  When I asked whether to "freeze" 1.8 last
time, this list's answer was "no".
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/9493

So I know how you feel Charlie.  I once was at your point.  What I learned was
that core people are geeks; they are destined to write new codes.  We have to
interact with them.

> It's to be expected alternative impls will always be chasing the
> "current" Ruby, but releases like 1.8.7 make even harder to find a
> slow-moving target to build toward. We do not want to abandon 1.8.6
> users, but with an even smaller dev team than core Ruby, we can't afford
> to maintain N branches for N production versions of Ruby. So for the
> moment, we only have resources to do 1.8.6 and 1.9.1, with a huge
> emphasis on 1.8.6.

Talking about human resources, there are total of 1.0 people to maintain both
1.8.6 and 1.8.7 branches, that is, myself. (plus another 1.0 people for 1.9.1,
who is yugui.)  This is why we cannot last 1.8.6 forever; MRI also lacks
developers to do that.  When we release 1.8.8, whatever that may be, I cannot
handle 3 branches at one time.

# A few more hands of people change this picture.

> And then this also affects adoption of the other releases. We've heard
> from many people that have not moved to 1.8.7 or 1.9.1 because the
> alternative impls have only been 1.8.6 compatible. We've heard from
> others that they might consider moving to 1.9.1 once JRuby has support.
> And at the same time we hear from users who see our continuing work on
> making JRuby's 1.8.6 mode more and more solid and want us to stay there
> forever. It's a balancing act complicated by having many drastically
> different production branches of the C impl.

There is another balancing act MRI faces.  MRI was born to be a geek toy.
People have won its control little by little and geek sandboxes are now very
limited.  But once people completely take that away from geeks, what happens --
a plateau.  Their new ideas to be used by all Rubyists is the biggest source of
their motivation.  Ruby cannot work without that.

Now I think difference in MRI branches are some kind of necessary evil, costs
that Ruby users should pay.  JRuby people are paying that cost too much and
there must be a better meeting point, but it is not realistic to completely
abandon new features and stick developers to 1.8.6.

> A lot of this would also be helped by getting the implementer meetings
> going again. We could talk through these concerns. I'm convinced most of
> the confusion around 1.8.7 could have been avoided with more communication.

Agreed.  A concensus is essential to an activity like Ruby releasing.