Re: Recent changes in Range#step behavior

Charles Oliver Nutter wrote:
> Daniel DeLorme wrote:
>> Since this is open to interpretation, I would suggest like David that 
>> the behavior should remain backward compatible. Besides, it's always 
>> possible to test for discrete membership by converting to enum.
> 
> Ruby 1.9.0 has been clearly described as a work in progress...it's a 
> development release, and functionality changes that are deemed to be 
> behavioral regressions should most definitely be fixed.

Charlie,

I think you're wrong. The development phase for 1.9 lasted until 
12/25/07, when 1.9.0 was released. 1.9 is a stable branch, but 1.9.0 is 
not ready for production use.  What is going on now is bug-fixing and 
fine-tuning of the stable release, not continued development of new 
features.

To support my claim, I cite this message from matz:

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/14389

That message includes the following:

>   * The relase version will be 1.9.0, not 1.9.1 as we have
>     announced before.  This denotes the fact it is not as
>     stable as we expected.  But the all incompatible changes
>     are done already.

Also,  on the same thread, is this exchange between you, Charlie, and matz:

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/14394

> In message "Re: pre-release note for the christmas release."
>     on Tue, 25 Dec 2007 05:12:15 +0900, Charles Oliver Nutter <charles.nutter / sun.com> writes:
> 
> |Can we expect no more features or incompatible changes between 1.9.0 and 
> |whatever becomes 1.9.1? In other words, would it be safe for us on JRuby 
> |to start implementing our 1.9 features based on what's released as 1.9.0?
> 
> Yes, basically, except for the possibility that we have to fix
> something we have designed severely wrong, if any.
> 
> |Also, does this officially mean that the release is considered "unstable"?
> 
> I don't consider it "production level".  Bugs may remained.  But we
> try making it stable.
> 
> 							matz.



> Part of the peril of releasing any book based on 1.9.0 is that there 
> simply *are* going to be changes. That's just how it is. Release errata 
> or new editions, but the truth of the matter is that 1.9.0 has never 
> been set in stone.

Not set in stone, but the bar for incompatible changes is high: only to 
fix things that are "severely wrong".   (And for the record, I'm not 
engaging this argument as strongly as I am because of its potential 
effect on my book--I'm already going to have to release a number of 
errata, and it would be easy enough to include a change to Range in 
that.  I'm arguing against this change because I think it is a bad idea.)

> If it seems like this should be changed, it should be changed. We can't 
> claim that just because it went out in a development release that it's 
> somehow a backward-incompatible change to fix it.

Anyone who wants to argue that this should be changed needs to go back 
and do the research to understand why Matz changed numeric range 
membership testing from discrete to continuous in the first place.  It 
is not sufficient to make an argument based on the set-like semantics of 
the word "member". There is some reason that the discrete membership 
changed to continuous membership, and that has got to be part of the 
context of this discussion.

Next, you must argue that this issue rises to the level of "severely 
wrong"--which is Matz's criteria for making incompatible changes. I 
think the fact that this feature has been in place, apparently without 
complaint, for 4 years will make it hard to argue for its severity.

     David

> - Charlie
> 
>