I am setting up two threads in the hopes that we can see names attached to opinions about the decision to break backwards compatibility between Ruby 1.8.6 and Ruby 1.8.7+ This one is for those who wish that Ruby 1.8 would go *back* to being 1.8.6 compatible in Ruby 1.8.8. If you agree with this, share your thoughts or at least a simple '+1'. If you disagree, please find the other thread titled 'If you are happy with the direction of Ruby 1.8.7, respond'. If you are in the middle, I don't know what you should do... write two posts? My goal is to survey ruby-talk so that the core Ruby team has a chance to see what people really want. I'm curious to see if this is as one-sided as I think it is.
on 11.02.2009 18:14
on 11.02.2009 18:19
Whoops, regretting this idea already, but I need to correct this: This thread is for if you are *happy* with the backports from Ruby 1.9 and want to see more. If you agree, share your thoughts. If you disagree, please find the 'if you are unhappy with the direction of 1.8.7+' post. On Wed, Feb 11, 2009 at 12:13 PM, Gregory Brown
on 11.02.2009 18:19
+1, even though you failed at changing the text of this mail compared to the other one.
on 11.02.2009 18:23
On Wed, Feb 11, 2009 at 12:17 PM, Dominik Honnef <dominikho@gmx.net> wrote: > +1, even though you failed at changing the text of this mail compared > to the other one. Noticed that just after I posted, sorry.
on 11.02.2009 19:00
I'm writing two posts. A side effect of 1.8.7 is, it sort of pulls the rug out from under people wanting to stay on the older, stable version. I really don't see a reason why 1.8 shouldn't have features like Symbol#to_proc, or Object#tap, or the other things I like from 1.9 -- even some of the syntax seems harmless, and unlikely to break anything. Also, as a user, it seems everything I try works on 1.8.7, while not everything works on 1.9 yet. So either it really is a gentler upgrade, or people are feeling compelled to have their gems working on the latest stable version. So in cases where I can't use 1.9, I can at least get closer.
on 11.02.2009 21:22
On Thu, 12 Feb 2009, Gregory Brown wrote: > My goal is to survey ruby-talk so that the core Ruby team has a chance > to see what people really want. I'm curious to see if this is as > one-sided as I think it is. Always make forward progress. I'm happy to move to 1.91 and beyond asap. That's why I have a really good suite of unit tests. To catch most of that class of breakage. John Carter Phone : (64)(3) 358 6639 Tait Electronics Fax : (64)(3) 359 4632 PO Box 1645 Christchurch Email : john.carter@tait.co.nz New Zealand
on 11.02.2009 21:32
On Wed, Feb 11, 2009 at 3:18 PM, John Carter <john.carter@tait.co.nz> wrote: > On Thu, 12 Feb 2009, Gregory Brown wrote: > >> My goal is to survey ruby-talk so that the core Ruby team has a chance >> to see what people really want. I'm curious to see if this is as >> one-sided as I think it is. > > Always make forward progress. I'm happy to move to 1.91 and beyond > asap. This isn't about Ruby 1.9.1. I'm all for that migration too. (My book "Ruby Best Practices" is on Ruby 1.9.1 *only*) I'm talking specifically about the 1.8 branch here. -greg
on 11.02.2009 21:40
On Feb 11, 10:12 am, Gregory Brown <gregory.t.br...@gmail.com> wrote: > My goal is to survey ruby-talk so that the core Ruby team has a chance > to see what people really want. I'm curious to see if this is as > one-sided as I think it is. Given that I have my own fork, I would say the answer is no, I'm not happy with the direction of 1.8.x. :) Regards, Dan
on 11.02.2009 22:23
2009/2/11 Gregory Brown <gregory.t.brown@gmail.com>: > I am setting up two threads in the hopes that we can see names > attached to opinions about the decision to break backwards > compatibility between Ruby 1.8.6 and Ruby 1.8.7+ Can you show us some examples of 1.8.6 code that doesn't work in 1.8.7? Regards, Pit
on 11.02.2009 22:47
On Wed, Feb 11, 2009 at 10:21 PM, Pit Capitain <pit.capitain@gmail.com> wrote: > h={} h[{"foo" => 1}] = 100 p h[{"foo" => 1}] ruby 1.8.6 prints "nil", 1.8.7 prints "100". -- Pozdrawiam Radosław Bułat http://radarek.jogger.pl - mój blog
on 11.02.2009 23:03
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, so I see this more like a "feature" fix (not a bug fix, because it hasn't been an official bug AFAIK). I can't imagine any code that depends on the behaviour of 1.8.6. Or do you have an example? Regards, Pit
on 11.02.2009 23:13
On Thu, Feb 12, 2009 at 02:12:14AM +0900, Gregory Brown wrote: > I am setting up two threads in the hopes that we can see names > attached to opinions about the decision to break backwards > compatibility between Ruby 1.8.6 and Ruby 1.8.7+ Mostly happy. I haven't seen the bogeymen reported by many people in 1.8.7. There is String#chars, but that seemed pretty easy to move past. If there are crashes, pull out gdb and let's see them. Shoes has had Ruby 1.8.7 within, since shortly after it was released. Folks, I'd stay away from the heavy-handed approach with Matz. He doesn't respond to a mob. And despite all the hype and business that now revolves around Ruby, it's still the man's language and his life work. Sometimes this community feels like one of those marriages where the lady marries the guy because she thinks she can change the guy. But the guy's the guy! I don't know. _why
on 11.02.2009 23:27
_why wrote: > Folks, I'd stay away from the heavy-handed approach with Matz. He > doesn't respond to a mob. And despite all the hype and business that > now revolves around Ruby, it's still the man's language and his life > work. +1
on 11.02.2009 23:43
On Feb 11, 2009, at 5:11 PM, _why wrote: > Folks, I'd stay away from the heavy-handed approach with Matz. He > doesn't respond to a mob. And despite all the hype and business that > now revolves around Ruby, it's still the man's language and his life > work. > > ... > _why > +1 for either path that is taken.
on 12.02.2009 00:29
On Feb 11, 2009, at 4:11 PM, _why wrote: > Folks, I'd stay away from the heavy-handed approach with Matz. He > doesn't respond to a mob. I agree with this fully and I don't feel like I've joined a mob. I'm not angry or out of control. I'm saying the new version process scare me. It's just an FYI for Matz and the core team. If they ignore it, well, that's how it goes. :) James Edward Gray II
on 12.02.2009 00:37
On Wed, Feb 11, 2009 at 5:11 PM, _why <why@ruby-lang.org> wrote: > Folks, I'd stay away from the heavy-handed approach with Matz. He > doesn't respond to a mob. And despite all the hype and business that > now revolves around Ruby, it's still the man's language and his life > work. Ah, but it's not Matz's issue. I actually love Ruby 1.9.1, and every time I ask Matz about this he says "I don't maintain 1.8". The issue is not with change, but with change that something that was previously labeled non-changing in a defacto way . -greg
on 12.02.2009 01:20
On Wed, Feb 11, 2009 at 12:37 PM, Daniel Berger <djberg96@gmail.com> wrote: > Given that I have my own fork, I would say the answer is no, I'm not > happy with the direction of 1.8.x. :) Could you give me a link to that fork? -- M. Edward (Ed) Borasky I've never met a happy clam. In fact, most of them were pretty steamed.
on 12.02.2009 11:27
_why wrote: > Folks, I'd stay away from the heavy-handed approach with Matz. He > doesn't respond to a mob. And despite all the hype and business that > now revolves around Ruby, it's still the man's language and his life > work. > > Sometimes this community feels like one of those marriages where the > lady marries the guy because she thinks she can change the guy. > But the guy's the guy! I don't know. Unless, of course, the guy can be convinced that he's causing the lady some sort of pain and seek to change himself. Quietly ignoring the problem is what *leads* to mobs and divorces. I think what we're doing here is entirely appropriate: raise concerns, discuss, hope for change or compromise. It may be Matz's language, but it's everyone's community. - Charlie
on 12.02.2009 12:50
> Given that I have my own fork, I would say the answer is no, I'm not > happy with the direction of 1.8.x. :) This is the happy thread and I'm happy with 1.8.7 -- well, sort of but I personally like the changes I know of. I have to say though that I find the idea to backport even more 1.9 features to 1.8 as strange as the idea to forget about 1.8.7 and move back to 1.8.6. I'd have expected 1.8 to be in maintenance mode after 1.9.1 was released.
on 12.02.2009 13:58
On Wed, Feb 11, 2009 at 6:35 PM, Gregory Brown <gregory.t.brown@gmail.com>wrote: > previously labeled non-changing in a defacto way . > Right to the point! I too love Ruby 1.9.1 and Matz! but... Ruby 1.8 (excluding 1.8.7) and Ruby 1.9 are really two different languages, I can deal with that as long as I know, and can control which of the two I'm using at any given time for any given application. Matz ceded maintenance of the "1.8" stream and moved on to 1.9 some time ago. The 1.8.7 release, rather than simply fixing bugs and maintaining compatibility, was attracted by "shiny objects" from 1.9 and wreaked havoc on some important consumers of Ruby, exacerbated by the eagerness of downstream package maintainers to keep up without understanding the ramifications of the breach of the implication of compatibility between versions with the same minor version number. Ruby 1.8.6 represents the latest version of the old Ruby language, 1.9.1 is the latest version of the new Ruby language, Ruby 1.8.7 is a mutant which just muddies the waters. -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Twitter: http://twitter.com/RickDeNatale
on 12.02.2009 16:55
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
on 12.02.2009 17:01
2009/2/12 Jeremy Henty <onepoint@starurchin.org> > > 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. Though I fall on the 'unhappy' side, this change is clearly fine: 1.8.6 behaviour is clearly a bug and should be fixed, that's the point of bug fix releases. Relying on buggy behaviour is a bad idea, and so is making changes to ostensibly correct behaviour in minor releases.
on 12.02.2009 17:16
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
on 12.02.2009 18:13
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
on 12.02.2009 18:55
On Thu, Feb 12, 2009 at 10:59 AM, James Coglan <jcoglan@googlemail.com>wrote: > > > Ah, you mean Hash#hash. Thanks a lot, I didn't know that. But this > releases. Relying on buggy behaviour is a bad idea, and so is making > changes > to ostensibly correct behaviour in minor releases. > The problem is that one man's bug is another's breaking change. Lot's of people always found the fact that Strings acted like collections of character codes rather than characters as a bug. >ruby -e'p "abc"[0]' 97 fixed by 1.9 >ruby1.9 -e'p "abc"[0]' "a" But there is a lot of Ruby <1.8.7 code whose correct behavior depends on that "bug" considering it part of the old Ruby language definition. And there's lots of history of that behavior being defined not as a bug but as the way that Ruby works. The problem with making semantic changes like this, whether they are pseudo-bugfixes or not, is that it's very hard to sort out ahead of time what impact they will have on the installed base of code using the 'stable' version. -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Twitter: http://twitter.com/RickDeNatale
on 12.02.2009 20:37
> result as 1.8.6 . That is the point.
I did not know 1.8.6 returned the counterintuitive result. Hence...
on 13.02.2009 02:20
On 2009-02-12, James Coglan <jcoglan@googlemail.com> wrote: >> That is the point. > > Though I fall on the 'unhappy' side, this change is clearly fine: > 1.8.6 behaviour is clearly a bug and should be fixed, that's the > point of bug fix releases. Relying on buggy behaviour is a bad idea, > and so is making changes to ostensibly correct behaviour in minor > releases. OK, I accept your point for this particular change. It doesn't hold for other changes, eg. methods returning Enumerators when they used to return Arrays. Regards, Jeremy Henty
on 13.02.2009 09:32
2009/2/13 Jeremy Henty <onepoint@starurchin.org>: > OK, I accept your point for this particular change. It doesn't hold > for other changes, eg. methods returning Enumerators when they used to > return Arrays. Jeremy, can you show us an example? Regards, Pit
on 13.02.2009 14:15
I am indifferent to it, may I post here as well? :-) My only general complaint would be that I think that some releases may have more bugs than others. Maybe a year ago, the ruby release candidate for some 1.9.x version had an irb which segfaulted for me. The later 1.9.x irb didn't segfault anymore. Irb is quite important for me so I was surprised to see irb has had difficulties. My wish would be that the amount of bugs is kept to a minimum.
on 13.02.2009 20:25
On 2009-02-13, Pit Capitain <pit.capitain@gmail.com> wrote: > 2009/2/13 Jeremy Henty <onepoint@starurchin.org>: >> OK, I accept your point for this particular change. It doesn't hold >> for other changes, eg. methods returning Enumerators when they used to >> return Arrays. > > Jeremy, can you show us an example? Annoyingly, no. I was repeating something I was sure had been said elsewhere in these threads, but despite having trawled around my news server and Google groups I can't find the post. So maybe I *have* been spreading FUD after all. :-( My apologies if so. Regards, Jeremy Henty
on 16.02.2009 04:59
On Wed, Feb 11, 2009 at 10:12 AM, Gregory Brown <gregory.t.brown@gmail.com>wrote: > This one is for those who wish that Ruby 1.8 would go *back* to being > 1.8.6 compatible in Ruby 1.8.8. If you agree with this, share your > thoughts or at least a simple '+1'. If you disagree, please find the > other thread titled 'If you are happy with the direction of Ruby > 1.8.7, respond'. If you are in the middle, I don't know what you > should do... write two posts? > If you ask me, what the Pythonistas got right that Ruby 1.8.7+ does not is: from __future__ import x I think it's great that Ruby 1.8.7+ wants to include all these nifty 1.9 features. But, I don't think they should be "on" by default. I think it'd be great if certain features (e.g. the 1.9.x enumerators) were available if you were to, say, require "future/enumerator" or something. If that were the case, I'd be on board with backporting everything, although changes to the grammar of the language itself might be difficult to enable in this manner, and many bring backwards compatibility issues.