# If you are unhappy with the direction of Ruby 1.8.7+, respond

**URL:** <https://www.ruby-forum.com/t/if-you-are-unhappy-with-the-direction-of-ruby-1-8-7-respond/160090>\
**Category:** Ruby\
**Created:** [February 11, 2009, 6:12pm UTC](https://www.ruby-forum.com/t/if-you-are-unhappy-with-the-direction-of-ruby-1-8-7-respond/160090 "2009-02-11T18:12:33Z")\
**Posts on this page:** 20\
**Page:** 7

<div class="post-metadata">

**Author:** ![naething](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/e47774/32.png) [@naething](https://www.ruby-forum.com/u/naething)\
**Post date:** [February 13, 2009, 6:25am UTC](https://www.ruby-forum.com/t/if-you-are-unhappy-with-the-direction-of-ruby-1-8-7-respond/160090/121 "2009-02-13T06:25:40Z")

</div>

pat eyler wrote:

> > confusing as to which Ruby I should be using. I understand that  
> > 1.8.6 via Pickaxe is a standard and so is 1.9.1 via David Black’s  
> > upcoming book.

Have you at work been using practices as egregiously substandard  
as top-posting?

---

<div class="post-metadata">

**Author:** ![naething](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/e47774/32.png) [@naething](https://www.ruby-forum.com/u/naething)\
**Post date:** [February 13, 2009, 7:26am UTC](https://www.ruby-forum.com/t/if-you-are-unhappy-with-the-direction-of-ruby-1-8-7-respond/160090/122 "2009-02-13T07:26:32Z")

</div>

Alex F. wrote:

> > We know the Rails issue (and solved), but could you elaborate on  
> > issues with wxRuby and SWIG?
> 
> [http://sourceforge.net/tracker2/?func=detail&aid=2034216&group\_id=1645&atid=101645](http://sourceforge.net/tracker2/?func=detail&aid=2034216&group_id=1645&atid=101645)

This is not our fault. Please hold on and think yourself. GC is  
running means  
ruby interpreter is running out of memory. It is as clear as day that  
object  
allocation during GC is not doable, because we do not have any memory  
space.

So SWIG had a bug. 1.8.7 helped to find it out.

---

<div class="post-metadata">

**Author:** ![naething](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/e47774/32.png) [@naething](https://www.ruby-forum.com/u/naething)\
**Post date:** [February 13, 2009, 8:19am UTC](https://www.ruby-forum.com/t/if-you-are-unhappy-with-the-direction-of-ruby-1-8-7-respond/160090/123 "2009-02-13T08:19:13Z")

</div>

On 12/02/2009, M. Edward (Ed) Borasky [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> > What I was supporting was a stable ‘flavor’ of Ruby 1.8, in the form  
> > _their_ user base to have working Ruby and Rails and gems! Right now,  
> > I’m running openSUSE 11.1, which ships 1.8.7. IIRC RHEL 5 / CentOS 5  
> > are still shipping 1.8.5, and I have no idea what’s in the two most  
> > recent versions of Ubuntu, or what’s going to be in Debian Lenny when

1.8.7, obviously. It’s there for ages already, and lenny is frozen  
since some time like end of year.

> it releases in the near future. In short, the distro Ruby herds need  
> to be in the loop, or the Ruby community will have a bunch of  
> implementations to choose from.

Or rather to not choose from unless you are willing to build your own.

Thanks

Michal

---

<div class="post-metadata">

**Author:** ![naething](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/e47774/32.png) [@naething](https://www.ruby-forum.com/u/naething)\
**Post date:** [February 13, 2009, 8:35am UTC](https://www.ruby-forum.com/t/if-you-are-unhappy-with-the-direction-of-ruby-1-8-7-respond/160090/124 "2009-02-13T08:35:39Z")

</div>

Urabe S. wrote:

> Alex F. wrote:
> 
> > > We know the Rails issue (and solved), but could you elaborate on  
> > > issues with wxRuby and SWIG?  
> > > [http://sourceforge.net/tracker2/?func=detail&aid=2034216&group\_id=1645&atid=101645](http://sourceforge.net/tracker2/?func=detail&aid=2034216&group_id=1645&atid=101645)
> 
> This is not our fault. Please hold on and think yourself. GC is running means  
> ruby interpreter is running out of memory. It is as clear as day that object  
> allocation during GC is not doable, because we do not have any memory space.
> 
> So SWIG had a bug. 1.8.7 helped to find it out.

Thanks. I perfectly understand the reason for the change, although the  
old behaviour worked fine in practice and libraries (not just SWIG ones)  
relied on it. It can be seen “fixing broken behaviour” though IMHO  
changing expectations of how GC works would better have been left for  
1.8-\>1.9 transition.

My concern about 1.8.7 has always been more that code written for 1.8.7  
is not necessarily compatible with 1.8.6, not the other way around - and  
to a much greater degree than previous .x releases. The problem is with  
expected and actual meaning of version numbers, not the code itself.

Anyway, I’m not going to stop using ruby just because it has an  
idiosyncratic versioning scheme. Thanks to all for a useful and mostly  
temperate discussion.

alex

---

<div class="post-metadata">

**Author:** ![naething](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/e47774/32.png) [@naething](https://www.ruby-forum.com/u/naething)\
**Post date:** [February 13, 2009, 8:23am UTC](https://www.ruby-forum.com/t/if-you-are-unhappy-with-the-direction-of-ruby-1-8-7-respond/160090/125 "2009-02-13T08:23:55Z")

</div>

Hi,

In message “Re: If you are unhappy with the direction of Ruby 1.8.7+,  
respond”  
on Fri, 13 Feb 2009 03:13:05 +0900, “M. Edward (Ed) Borasky”  
[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) writes:

|1. Would there be a chance of merging the efficiencies of Ruby  
|Enterprise Edition, especially copy-on-write friendliness, into the  
|“Engine Y. 1.8.6 stack?”

No please. Any new technology for 1.8 should merged in HEAD first,  
then merged back into 1.8.6 if appropriate. I am not going to allow  
EngineYard to fork off 1.8.6. If people from EngineYard want to  
improve 1.8, it’s OK. We are open. I will give them commit privilege  
even. But no fork.

```
          matz.

```

---

<div class="post-metadata">

**Author:** ![naething](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/e47774/32.png) [@naething](https://www.ruby-forum.com/u/naething)\
**Post date:** [February 13, 2009, 8:43am UTC](https://www.ruby-forum.com/t/if-you-are-unhappy-with-the-direction-of-ruby-1-8-7-respond/160090/126 "2009-02-13T08:43:20Z")

</div>

On 13/02/2009, Yukihiro M. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> I think he relied on the version/implementation specific behavior, so  
> 1.8.7 HELPED to find a bug in HIS code, unless I am wrong in any ways.  
> Any other example of 1.8.7 incompatibility?
> 
> I am not happy with FUD-like attitude against 1.8.7. From my point of  
> view, 1.8.7 is a good release with unfortunate beginning. There are  
> slight incompatibility, but every past releases also had some sort of  
> incompatibilities as well. I’d like to use 1.8.7 to write new 1.8  
> code.

I’m sorry if I personally added to this kind of view. Unlike earlier  
releases I had some minor problem with code not running after upgrade  
to 1.8.7, and it seemed many other people have similar experience.  
While acceptable for your own code it is not good for code you  
distribute to somebody else.

Back then nobody stepped up and said that if code working on 1.8.6  
broke it is a bug so I just left it at that - the compatibility seemed  
to be not so great. I have not experienced the same with earlier  
versions. There was some issue in the past when a bug in the  
interpreter was fixed and it broke a C extension that relied on the  
bug and was widely used but it was a single, well understood issue.

The real indisputable failing of 1.8.7 is the introduction of many new  
convenience methods into the core classes. If these were separated  
into an extension (perhaps one which could be built for 1.8.6 as well)  
which was not automatically loaded it would be fine and useful to have  
them. As things are now the new methods are often convenient and  
somebody coding on 1.8.7 would likely use the new methods making the  
code unusable on 1.8.6 and earlier. Been there, done that - as many  
people did.

Thanks

Michal

---

<div class="post-metadata">

**Author:** ![naething](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/e47774/32.png) [@naething](https://www.ruby-forum.com/u/naething)\
**Post date:** [February 13, 2009, 9:12am UTC](https://www.ruby-forum.com/t/if-you-are-unhappy-with-the-direction-of-ruby-1-8-7-respond/160090/127 "2009-02-13T09:12:40Z")

</div>

Hi,

In message “Re: If you are unhappy with the direction of Ruby 1.8.7+,  
respond”  
on Fri, 13 Feb 2009 16:41:25 +0900, Michal S.  
[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) writes:

|I’m sorry if I personally added to this kind of view. Unlike earlier  
|releases I had some minor problem with code not running after upgrade  
|to 1.8.7, and it seemed many other people have similar experience.  
|While acceptable for your own code it is not good for code you  
|distribute to somebody else.  
|  
I expect you to be more concrete and specific about minor problems.  
As far as I know:

- Rails had problem from method name conflict. This was  
unfortunate, caused by Rails’ fragile monkey patching and our bad  
for lack of thorough Rails test before 1.8.7. It is fixed now.

- erb also had a bug in 1.8.7 initial release. It is fixed now.

- two other problems are reported (SWIG and hash order), and as far  
as I understand, they both contain bugs that haven’t disclosed for  
1.8.6 by accident.

I consider them minor and not being worse than previous releases.  
Most of them are addressed already. Am I missing something?

|Back then nobody stepped up and said that if code working on 1.8.6  
|broke it is a bug so I just left it at that - the compatibility seemed  
|to be not so great.

If compatibility of 1.8.7 is really “not so great”:

- if it is fixable, we can fix.

- if it is minor, we can upgrade 1.8.7 (or later) whenever we want,  
as we did in the past.

- if upgrading is not affordable for enterprisey people (yes, I  
understand them; upgrading is costly even when incompatibility is  
minor), they can keep using 1.8.6, which is maintained right now.  
As EngineYard raised their hands, the maintenance of 1.8.6 will be  
kept, even after 1.8.8.

If more evidence of great incompatibility is not shown, I will  
consider it FUD, or FUD-like at most, even though I see no bad  
intention from anyone.

```
          matz.

```

---

<div class="post-metadata">

**Author:** ![naething](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/e47774/32.png) [@naething](https://www.ruby-forum.com/u/naething)\
**Post date:** [February 13, 2009, 9:52am UTC](https://www.ruby-forum.com/t/if-you-are-unhappy-with-the-direction-of-ruby-1-8-7-respond/160090/128 "2009-02-13T09:52:12Z")

</div>

On 13/02/2009, Yukihiro M. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> |distribute to somebody else.  
> |
> 
> I expect you to be more concrete and specific about minor problems.

Yes, I would like to be more concrete. Unfortunately, it’s some time  
since 1.8.7 was released and I do not have any of the code at hand.

> As far as I know:
> 
> - Rails had problem from method name conflict. This was  
> unfortunate, caused by Rails’ fragile monkey patching and our bad  
> for lack of thorough Rails test before 1.8.7. It is fixed now.

This was well understood from the start, and easy enough to fix.

Again, if the many methods added were optional such situations could be  
avoided.

> - erb also had a bug in 1.8.7 initial release. It is fixed now.
> 
> - two other problems are reported (SWIG and hash order), and as far  
> as I understand, they both contain bugs that haven’t disclosed for  
> 1.8.6 by accident.

The SWIG problem was until recently described as something like “many  
C extensions fail”. I personally don’t care as I don’t use them but I  
would not upgrade to 1.8.7 a package in a system distriution be cause  
of this.

It’s obviously a change of expectations on which many C extensions  
rely. While this might be a step towards making the GC “more correct”  
the old behaviour was “safe enough” and the fix is not localized into  
replacing a single bit - many C extensions will have to change so this  
might not be considered minor.

> If compatibility of 1.8.7 is really “not so great”:
> 
> - if it is fixable, we can fix.

I guess saying this is exactly what the 1.8.7 release was missing at the  
start.

There were people saying it breaks things, and no obvious progress  
towards fixing the issues. When I got 1.8.7 in an overall system  
upgrade I also had to modify code which I believed to work on 1.8.6.

> If more evidence of great incompatibility is not shown, I will  
> consider it FUD, or FUD-like at most, even though I see no bad  
> intention from anyone.

Yes, the attitude towards 1.8.7 evolved in an unfortunate way.

And I think some of the uncertainty resulted from lack of  
communication on part of the core team.

Thanks

Michal

---

<div class="post-metadata">

**Author:** ![naething](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/e47774/32.png) [@naething](https://www.ruby-forum.com/u/naething)\
**Post date:** [February 13, 2009, 9:43am UTC](https://www.ruby-forum.com/t/if-you-are-unhappy-with-the-direction-of-ruby-1-8-7-respond/160090/129 "2009-02-13T09:43:21Z")

</div>

> Your code happened to work by chance.

Granted. As I’ve said elsewhere, this is just my example of a  
significant  
change in 1.8.7. I accept that no iteration order was ever explicitly  
stated  
for 1.8, and a change like this is something of a grey area in terms of  
whether it would be considered a backward incompatibility.

> > To work with 1.8.7, you need to create an empty hash  
> > and add keys one by one rather than putting them all in a hash literal  
> > (see  
> > the patch).
> 
> Do I understand that the code relies on insertion order now?  
> Then it’s still working by chance in case it works at all.

I may have misstated this: it does rely on insertion order, but I  
maintain  
that explicitly in my code now – I’m not relying on Ruby to do it for  
me.

---

<div class="post-metadata">

**Author:** ![naething](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/e47774/32.png) [@naething](https://www.ruby-forum.com/u/naething)\
**Post date:** [February 13, 2009, 10:56am UTC](https://www.ruby-forum.com/t/if-you-are-unhappy-with-the-direction-of-ruby-1-8-7-respond/160090/130 "2009-02-13T10:56:03Z")

</div>

2009/2/13 William J. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)

> > Your code happened to work by chance.  
> > +1
> 
> Mr. Coglan seems not to understand how a hash-table is implemented.  
> One cannot predict the iteration order because he cannot know in which  
> bucket each element has been stored. Furthermore, it makes no sense  
> at all to be concerned about iteration-order for a hash-table.
> 
> If one is concerned about iteration-order, he should use an  
> association-list.

I do know how hash tables work, I was responding to the question of  
whether  
any code was broken by 1.8.7. I’ve conceded elsewhere in this thread  
that no  
iteration order was ever guaranteed for 1.8, and that the question of  
whether this counts as a true backward incompatibility is a grey area at  
best.

I am using an ordered hash implementation, but was initialising it using  
hash literals, which obviously does not work if iteration order is  
different  
from source order. I’ve since fixed the bug by adding keys explicitly  
one by  
one.

This begs the question of whether 1.9 should guarantee insertion order  
for  
hashes. Since hashes are not inherently ordered beings, wouldn’t it make  
more sense to provide an OrderedHash subclass that explicitly provides  
that  
behaviour? At least then it would be clearer if you were using a 1.9  
feature  
that won’t work on 1.8.

---

<div class="post-metadata">

**Author:** ![naething](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/e47774/32.png) [@naething](https://www.ruby-forum.com/u/naething)\
**Post date:** [February 13, 2009, 10:13am UTC](https://www.ruby-forum.com/t/if-you-are-unhappy-with-the-direction-of-ruby-1-8-7-respond/160090/131 "2009-02-13T10:13:21Z")

</div>

2009/2/13 James C. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid):

> I would concede that this is something of a grey area as it’s neither a bug  
> fix or an explicit feature addition, but the question was asked about 1.8.6  
> code that broke, and this is an example.

James, maybe you missed ruby-talk:327937  
([http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/327937](http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/327937)).  
Your code isn’t working reliably even on 1.8.6. Look at this IRB  
session I’ve just run on my ruby 1.8.6 (2007-03-13 patchlevel 0)  
[i386-mswin32]:

irb(main):001:0\> {2 =\> 0, 1 =\> 0}  
=\> {1=\>0, 2=\>0}  
irb(main):002:0\> {:a =\> 0, :z =\> 0}  
=\> {:a=\>0, :z=\>0}  
irb(main):003:0\>

As you can see, in one case the hash is iterated over in insertion  
order, in the other case not. It depends on the hash keys and maybe  
other factors. If your code was working for you you’ve just been  
lucky, but you can’t claim that this is an example for code that was  
working on 1.8.6. The code was broken in 1.8.6 and still is broken in  
1.8.7, and 1.8.7 even helped you find the bug in your code, as someone  
else had said already.

Regards,  
Pit

---

<div class="post-metadata">

**Author:** ![naething](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/e47774/32.png) [@naething](https://www.ruby-forum.com/u/naething)\
**Post date:** [February 13, 2009, 11:03am UTC](https://www.ruby-forum.com/t/if-you-are-unhappy-with-the-direction-of-ruby-1-8-7-respond/160090/132 "2009-02-13T11:03:54Z")

</div>

Hi,

In message “Re: If you are unhappy with the direction of Ruby 1.8.7+,  
respond”  
on Fri, 13 Feb 2009 17:50:02 +0900, Michal S.  
[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) writes:

|Yes, the attitude towards 1.8.7 evolved in an unfortunate way.

Indeed, and I want to fix it.

|And I think some of the uncertainty resulted from lack of  
|communication on part of the core team.

Communication has both side. Of course, core team can/should improve  
their attitude. But users might be able to improve how they report to  
the team. Some of the team claimed they didn’t get the concrete  
report more than complaining in some cases. And we now have Redmine  
to improve the communication.

```
          matz.

```

---

<div class="post-metadata">

**Author:** ![naething](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/e47774/32.png) [@naething](https://www.ruby-forum.com/u/naething)\
**Post date:** [February 13, 2009, 11:11am UTC](https://www.ruby-forum.com/t/if-you-are-unhappy-with-the-direction-of-ruby-1-8-7-respond/160090/133 "2009-02-13T11:11:48Z")

</div>

2009/2/13 William J. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)

> > incompatibility.
> 
> No, it’s not a gray area. Anyone who has a basic understanding of  
> hash-tables doesn’t even think about the iteration order.

Not true. Some languages (Ruby 1.9, most JavaScript implementations)  
iterate  
over hashtables in insertion order. This is often done (as it is in  
Ruby) by  
storing the table entries as a linked list so that every entry has  
pointers  
to its neighbours. Though a basic hashtable implementation will not  
guarantee iteration order, there is potential confusion if an  
implementation  
_appears_ to guarantee it. I referred to this is a grey area because 1.8  
never made any such promises, it just _looked_ like it did in some use  
cases  
until 1.8.7.

Anyway, this has gone a little off-topic. As previously stated, I would  
point out that [GitHub - jcoglan/packr at 3.1](http://github.com/jcoglan/packr/tree/3.1) still has a  
regex-related bug under 1.8.7 that I’ve not found a fix for and that  
does  
not appear in any other 1.8 or 1.9 release. If anyone has had regex  
issues  
on 1.8.7 I’d really love some help fixing my bug!

---

<div class="post-metadata">

**Author:** ![naething](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/e47774/32.png) [@naething](https://www.ruby-forum.com/u/naething)\
**Post date:** [February 13, 2009, 12:27pm UTC](https://www.ruby-forum.com/t/if-you-are-unhappy-with-the-direction-of-ruby-1-8-7-respond/160090/134 "2009-02-13T12:27:47Z")

</div>

Hi,

At Fri, 13 Feb 2009 16:33:38 +0900,  
Alex F. wrote in [ruby-talk:328029]:

> Thanks. I perfectly understand the reason for the change, although the  
> old behaviour worked fine in practice and libraries (not just SWIG ones)  
> relied on it. It can be seen “fixing broken behaviour” though IMHO  
> changing expectations of how GC works would better have been left for  
> 1.8-\>1.9 transition.

And the workaround has been introduced into 1.8.7 already, so  
those extensions would work without changing.

---

<div class="post-metadata">

**Author:** ![naething](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/e47774/32.png) [@naething](https://www.ruby-forum.com/u/naething)\
**Post date:** [February 13, 2009, 1:14pm UTC](https://www.ruby-forum.com/t/if-you-are-unhappy-with-the-direction-of-ruby-1-8-7-respond/160090/135 "2009-02-13T13:14:18Z")

</div>

Ezra Z. wrote:

> the whole ruby community. Please respond here if you think Engine yard  
> would make good maintainers of the ruby1.8.6 lineage
> 
> Thanks  
> Yes… (and thanks!)

---

<div class="post-metadata">

**Author:** ![naething](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/e47774/32.png) [@naething](https://www.ruby-forum.com/u/naething)\
**Post date:** [February 13, 2009, 10:56am UTC](https://www.ruby-forum.com/t/if-you-are-unhappy-with-the-direction-of-ruby-1-8-7-respond/160090/136 "2009-02-13T10:56:40Z")

</div>

James C. wrote:

> > Your code happened to work by chance.
> 
> Granted. As I’ve said elsewhere, this is just my example of a  
> significant change in 1.8.7. I accept that no iteration order was  
> ever explicitly stated for 1.8, and a change like this is something  
> of a grey area in terms of whether it would be considered a backward  
> incompatibility.

No, it’s not a gray area. Anyone who has a basic understanding of  
hash-tables doesn’t even think about the iteration order.

---

<div class="post-metadata">

**Author:** ![naething](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/e47774/32.png) [@naething](https://www.ruby-forum.com/u/naething)\
**Post date:** [February 13, 2009, 4:01pm UTC](https://www.ruby-forum.com/t/if-you-are-unhappy-with-the-direction-of-ruby-1-8-7-respond/160090/137 "2009-02-13T16:01:59Z")

</div>

James G. wrote:

> I have no problems with the 1.9 release. I feel like the reasoning has  
> been well explained and I understand it.
> 
> Essentially, a lot was promised for 2.0. About half of it has been  
> built. We could have kept waiting for the other half, or release what  
> was done. It’s not all of 2.0 though, so it’s instead called 1.9.

I suppose once all the smoke clears on the current discussion, dare I  
ask about the road map for the 1.9.x --\> 2.0 transition, and perhaps  
even more important, the _process_ for it?

## 

M. Edward (Ed) Borasky

I’ve never met a happy clam. In fact, most of them were pretty steamed.

---

<div class="post-metadata">

**Author:** ![naething](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/e47774/32.png) [@naething](https://www.ruby-forum.com/u/naething)\
**Post date:** [February 13, 2009, 3:38pm UTC](https://www.ruby-forum.com/t/if-you-are-unhappy-with-the-direction-of-ruby-1-8-7-respond/160090/138 "2009-02-13T15:38:06Z")

</div>

On Fri, Feb 13, 2009 at 12:15 AM, Nobuyoshi N.  
[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)wrote:

> > 
> 
> definitely a bug in your code as you use the word “order”.

Yes, and this particular kind of change, making something which was  
previously undefined now be defined, seems to be a benign change, since  
the  
defined behavior is within the ‘definition’ of the previous behavior.

## It’s the changing of defined behavior while implying compatibility which causes problems, particulary when the change is significant enough, or there are enough such changes. And when this threshold is crossed is, admittedly, subjective.

Rick DeNatale

Blog: [http://talklikeaduck.denhaven2.com/](http://talklikeaduck.denhaven2.com/)  
Twitter: [http://twitter.com/RickDeNatale](http://twitter.com/RickDeNatale)

---

<div class="post-metadata">

**Author:** ![naething](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/e47774/32.png) [@naething](https://www.ruby-forum.com/u/naething)\
**Post date:** [February 13, 2009, 4:08pm UTC](https://www.ruby-forum.com/t/if-you-are-unhappy-with-the-direction-of-ruby-1-8-7-respond/160090/139 "2009-02-13T16:08:31Z")

</div>

Ola B. wrote:

> > > lineage
> > 
> > +1
> > 
> > Although, I’m at a loss as to what you’d use for the version number on  
> > the  
> > first maintenance release.
> 
> What about 1.8.6.1?

Someone suggested having 1.8.8 being 1.8.6 syntax and semantics with  
only bug fixes, security fixes and efficiency enhancements. That appeals  
to me … that way, “1.8.7” is a development release and “1.8.8” is  
stable. But I would think EngineYard would want to “brand” their ruby  
1.8.6 implementation in a manner similar to Ruby Enterprise Edition.

BTW, Perl had no trouble going from 5.8.x to 5.10.x, and I understand  
there is a 5.12.x coming. So I don’t see a problem with Ruby doing  
similar things in the third digit. 1.8.10 works for me, as does 1.9.10.  
🙂

–  
M. Edward (Ed) Borasky

I’ve never met a happy clam. In fact, most of them were pretty steamed.

---

<div class="post-metadata">

**Author:** ![naething](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/e47774/32.png) [@naething](https://www.ruby-forum.com/u/naething)\
**Post date:** [February 13, 2009, 4:09pm UTC](https://www.ruby-forum.com/t/if-you-are-unhappy-with-the-direction-of-ruby-1-8-7-respond/160090/140 "2009-02-13T16:09:41Z")

</div>

On Fri, Feb 13, 2009 at 4:50 AM, James C.  
[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)wrote:

> This begs the question of whether 1.9 should guarantee insertion order for  
> hashes. Since hashes are not inherently ordered beings, wouldn’t it make  
> more sense to provide an OrderedHash subclass that explicitly provides that  
> behaviour? At least then it would be clearer if you were using a 1.9  
> feature  
> that won’t work on 1.8.

For Ruby 1.9, the issue is settled. Ruby 1.9 is a new and different  
Ruby  
than Ruby 1.8.6.

To make an analogy from ancient history, there is a Rubicon between Ruby  
1.8.6 and Ruby 1.9. Because of the consequences of crossing the  
Rubicon,  
one should make a conscious decision to do so.

Ruby 1.8.7 represents the middle of the river.

–  
Rick DeNatale

Blog: [http://talklikeaduck.denhaven2.com/](http://talklikeaduck.denhaven2.com/)  
Twitter: [http://twitter.com/RickDeNatale](http://twitter.com/RickDeNatale)

[Previous page](https://www.ruby-forum.com/t/if-you-are-unhappy-with-the-direction-of-ruby-1-8-7-respond/160090.md?page=6)

[Next page](https://www.ruby-forum.com/t/if-you-are-unhappy-with-the-direction-of-ruby-1-8-7-respond/160090.md?page=8)