I'm in the happy camp, mostly.  It's fine to add new features to an 
upwardly compatible release as long as one doesn't sacrifice the 
stability(given this is a "production" release) - i.e., upwardly 
compatible does NOT mean that feature set of version x.y.z should be the 
same as the feature set of x.y.z+1.  API compatibility across 'teeny' 
releases is important, and, is something Matz and others have 
professed(in a thread I don't have a pointer handy, but it's on ruby-core).

 Fixes to bugs, IMO, cannot be counted as making the software 
incompatible - if they did, the language implementation would get nowhere. 

 On the other hand, changes to the existing APIs that are not generally 
accepted as bugs definitely count as incompatibilities - IMO, it's this 
area thats tinged with shades of gray, since I cannot easily tell if 
some 'bug fixes' are indeed 'bug fixes' or if they break the 
compatibility expectations that the Ruby versioning system sets.(  I 
work for a Ruby vendor that, among other things, promises compatibility, 
and any mixed bag of fixes + compatibility breakages, if indeed it is 
so, is an issue to deal with).

Just my 2 cents,
 -ps


 




Coey Minear wrote:
> Jeremy Henty writes:
>  > On 2009-02-11, Pit Capitain <pit.capitain / gmail.com> wrote:
>  > > 2009/2/11 Rados?aw Bu?at <radek.bulat / gmail.com>:
>  > >> h={}
>  > >> h[{"foo" => 1}] = 100
>  > >> p h[{"foo" => 1}]
>  > >>
>  > >> ruby 1.8.6 prints "nil", 1.8.7 prints "100".
>  > >
>  > > Ah, you mean  Hash#hash. Thanks a lot, I didn't  know that. But this
>  > > is an example where the  1.8.7 version yields the result most people
>  > > would expect,
>  > 
>  > No  it doesn't.   Most people  would expect  1.8.7 to  yield  the same
>  > result as 1.8.6 .  That is the point.
>  > 
>  > Regards,
>  > 
>  > Jeremy Henty
>  > 
>
> As I read this, my feeling about what "most people" would expect
> should fall into one of two categories:
>  - hashes should allow (different) hashes to be used as keys; or
>  - hashes should _not_ allow hashes to be used as keys.
>
> If someone feels the first response is correct, then '100' would be
> what they expect from Ruby.  If someone feels the second response is
> correct, then they would probably expect a SyntaxError or RuntimeError
> exception to be thrown.
>
> So from my perspective, having a hash with a hash as a key return
> 'nil' is a bug (in the example given above, where it was previously
> set), and bugs should be fixed, in all versions.  You are arguing from
> the third camp of "I'm used to the bug so please don't fix it."
>
> Of course, these are just my opinions.  And in general, I do fall into
> the "don't change the API behavior between 1.8.6 and 1.8.7" camp.  But
> in this case, I would say the 1.8.6 behavior described is a bug and
> should be addressed.
>
>
> Coey Minear
>
>