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.

-greg

-- 
Technical Blaag at: http://blog.majesticseacreature.com
 Non-tech stuff at: http://metametta.blogspot.com
"Ruby Best Practices"  Book now in O'Reilly Roughcuts:
http://rubybestpractices.com

On Feb 11, 2009, at 11:10 AM, 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+
> 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.

I'm bothered by the new versioning scheme.

The new releases involve big changes and even if they are fully  
backwards compatible about what they will run, they are still creating  
pretty big compatibility gaps.  Code using any of the new 1.8.7  
features won't run on 1.8.6 and lower.  It sounds as if 1.8.8 intends  
to take this farther, so code written to that won't work in the  
different 1.8.7 branch or the earlier 1.8.6 and lower stuff.  Thus I  
feel we now have three different versions of Ruby 1.8 on the table  
(counting the not yet released 1.8.8).

James Edward Gray II

[Note:  parts of this message were removed to make it a legal post.]

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+
> 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?



I'm not sure whose problem this really is, but it's worth bearing in mind
that in certain Linux package systems, there is just one 'ruby1.8' package
and one 'ruby1.9' package, each of which ships the latest from that branch.
The same goes for the 'gem' executable, so you only get one gem repo per
'major' version -- you don't get a 1.8.6 gem repo and a 1.8.7 repo, you just
get one for all 1.8.x releases.

Keeping 1.8.x back-compatible with prior 1.8.x seems like it would minimise
confusion for a lot of people and reduce the burden of testing libraries
against multiple Rubys.

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+
> 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'. 

Gregory - thank you for raising this here. I read this ruby-core thread:
http://www.ruby-forum.com/topic/178191#new

last night, and in particular Akinori MUSHA's statement:

"Yes.  Backporting syntactic changes is a big part of the plan for ruby
1.8.8"

Luckily I was in bed else I'd have fallen off my chair. This seems to me 
the most bonkers development plan I've seen in a long while.

Stable releases are meant to be *stable*; minor point releases are meant 
to be *API compatible*, backwards and forwards. I can't think of any 
other serious open-source project that would even contemplate adding 
random bits of syntax and API calls in minor releases.

I expressed the same opinion at length and with some fervour regarding 
the release of 1.8.7: http://www.ruby-forum.com/topic/150251#663291

so I won't go on again. However one of the main reasons for allowing 
1.8.7 to cherry-pick backports was that, at the time of the decision, 
(Nov 2006) 1.9.1 seemed a while off, and some didn't want the language 
frozen until then. That seemed impatient to me then, but now there's a 
release version of 1.9.1 on the table, I can see no justifcation at all.

The progression to 1.9 isn't that hard anyway; the language hasn't 
changed so much. And I can't see that having a whole load of 
incompatible 1.8.x mongrel releases washing about (as they end up in 
distros etc) helps anyway.

Just to say again, I'm grateful for the work of the core developers and 
maintainers - but it seems like 1.8 branch is being treated like a 
personal playground rather than a stable version. There's not even a 
statement of what features might be backported.

Ooops, I've gone on at length again.

Anyway, +1 for Ruby 1.8.8 being a bugfix release implementing the same 
API as 1.8.6

alex

[Note:  parts of this message were removed to make it a legal post.]

+1

1.8 should keep its final branch release as fully 1.8 compatible for
posterity.  (Keep it legacy compatible)
Ventures into the future can take place inside the Newer 1.9 and 2.0
branches without breaking what we could call "1.8 Legacy" code.

2009/2/11 James Gray <james@grayproductions.net>

> On Feb 11, 2009, at 11:10 AM, 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+
>> 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.
>>
>
> I'm bothered by the new versioning scheme.
>
> The new releases involve big changes and even if they are fully backwards
> compatible about what they will run, they are still creating pretty big
> compatibility gaps.  Code using any of the new 1.8.7 features won't run on
> 1.8.6 and lower.  It sounds as if 1.8.8 intends to take this farther, so
> code written to that won't work in the different 1.8.7 branch or the earlier
> 1.8.6 and lower stuff.  Thus I feel we now have three different versions of
> Ruby 1.8 on the table (counting the not yet released 1.8.8).
>
> James Edward Gray II
>
>

I'll write two posts.

Now that 1.9.1 is released, hopefully people will start porting to it, 
and 1.8 can remain stable. For the people who still need all their old 
gems to work, there should be a stable version -- apparently, 1.8.7 
broke a lot of things.

On top of which, if 1.8.8 is an easier upgrade than 1.9, people won't be 
as encouraged to port to 1.9.
 

I wrote it on ruby-core and I write it again: I'm very worried and
confused with Ruby versioning policy.
I'm very unhappy with all 1.8.7 and possibly 1.8.8 version.

+1

--=20
Pozdrawiam

Rados=B3aw Bu=B3at
http://radarek.jogger.pl - m=F3j blog

I've posted my opinions on Ruby-Core, but I'll summarize them here:

1. The Ruby community should proceed with all deliberate speed towards
ISO standardization of the language.

2. There are two "de facto" standards for the Ruby language at present.
    a. Ruby 1.8.6 as documented in the Pickaxe, Second Edition
    b. Ruby 1.9.1 as documented in "The Well-Grounded Rubyist",
"Programming Ruby 1.9" and "The Ruby Programming Language".

   All other versions are irrelevant and a waste of precious developer
energy as far as I'm concerned.

3. I don't think it matters what the numbers are, but since the two
"de facto" standard versions have designated numbers already, why not
keep them as they are?

4. Since I don't personally have a large installed base of Ruby code,
I am going to use 1.9.1 whenever possible to
    a. Take advantage of the YARV engine.
    b. Put some mileage on the implementation, shake out the
documentation, performance tune, etc.
-- 
M. Edward (Ed) Borasky

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

I've posted my opinions on Ruby-Core, but I'll summarize them here:

1. The Ruby community should proceed with all deliberate speed towards
ISO standardization of the language.

2. There are two "de facto" standards for the Ruby language at present.
    a. Ruby 1.8.6 as documented in the Pickaxe, Second Edition
    b. Ruby 1.9.1 as documented in "The Well-Grounded Rubyist",
"Programming Ruby 1.9" and "The Ruby Programming Language".

   All other versions are irrelevant and a waste of precious developer
energy as far as I'm concerned.

3. I don't think it matters what the numbers are, but since the two
"de facto" standard versions have designated numbers already, why not
keep them as they are?

4. Since I don't personally have a large installed base of Ruby code,
I am going to use 1.9.1 whenever possible to
    a. Take advantage of the YARV engine.
    b. Put some mileage on the implementation, shake out the
documentation, performance tune, etc.
-- 
M. Edward (Ed) Borasky

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

I've posted my opinions on Ruby-Core, but I'll summarize them here:

1. The Ruby community should proceed with all deliberate speed towards
ISO standardization of the language.

2. There are two "de facto" standards for the Ruby language at present.
    a. Ruby 1.8.6 as documented in the Pickaxe, Second Edition
    b. Ruby 1.9.1 as documented in "The Well-Grounded Rubyist",
       "Programming Ruby 1.9" and "The Ruby Programming Language".

   All other versions are irrelevant and a waste of precious developer
   energy as far as I'm concerned.

3. I don't think it matters what the numbers are, but since the two "de
facto" standard versions have designated numbers already, why not keep
them as they are?

4. Since I don't personally have a large installed base of Ruby code, I
   am going to use 1.9.1 whenever possible to
    a. Take advantage of the YARV engine.
    b. Put some mileage on the implementation, shake out the
       documentation, performance tune, etc.
-- 
M. Edward (Ed) Borasky

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

I'm very unhappy. Come on people! Use standard versioning:

1.MAJOR_VERSION.MINOR_VERSION

Should mean that after each MINOR_VERSION change I won't loose 
compatibility of my code, and only known bugs will be fixed or 
performance improved! Backporting is unnecesary and confusing. Most 
people will stay on 1.8.6 (including me on my servers) until most of 
applications will work with 1.9.1.

Leave alone 1.8 branch, don't do such stupid things like You want to!!


+1 is not enough!
+666!  ;}
-- 
Posted via http://www.ruby-forum.com/.

+1

#include <all the other comments so far>

-- 
Aaron Turner
http://synfin.net/
http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix & Windows
Those who would give up essential Liberty, to purchase a little
temporary Safety,
deserve neither Liberty nor Safety.
    -- Benjamin Franklin

As a new Ruby user coming to the language, I've found it fairly  
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.

Coming from other projects, it would seem to me that making changes to  
1.8.x that aren't backwards compatible is a confusing message. I don't  
like the idea of have parts of 1.8.x incompatible with the rest of it.  
Thats nonsense.

+42 for not breaking backwards compatibility. 1.8.x made it this far,  
no need to introduce changes that are already in place in 1.9.x.

-Zac

On Feb 11, 2009, at 12:10 PM, 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+
> 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.
>
> -greg
>
> -- 
> Technical Blaag at: http://blog.majesticseacreature.com
> Non-tech stuff at: http://metametta.blogspot.com
> "Ruby Best Practices"  Book now in O'Reilly Roughcuts:
> http://rubybestpractices.com
>

+1

I had a brief foray into 1.8.7 and had problems deploying code to some
servers that were running 1.8.6 so now use 1.8.6.

Will switch to 1.9.x when all the stuff I need works with it, but
until then I'd really appreciate a proper and consistent 1.8.x branch
that didn't diverge into being a halfway house.

Backported stuff isn't what I want at all - when I want 1.9.x features
(and everything works with them) I'll move to 1.9 but please leave 1.8
alone!

Rupert

At work, we've already been bitten by 1.8.6 -> 1.8.7 problems.
I can't tell you how much I don't want to see 1.8.8 move even
further away from 1.8.6.

Please, leave the 1.8 line as compatible as possible, leave
the API breakage to the 1.8 -> 1.9 migration.

On Wed, Feb 11, 2009 at 12:00 PM, Zachary Brown <zac@zacbrown.org> wrote:
> As a new Ruby user coming to the language, I've found it fairly 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.
>
> Coming from other projects, it would seem to me that making changes to 1.8.x
> that aren't backwards compatible is a confusing message. I don't like the
> idea of have parts of 1.8.x incompatible with the rest of it. Thats
> nonsense.
>
> +42 for not breaking backwards compatibility. 1.8.x made it this far, no
> need to introduce changes that are already in place in 1.9.x.
>
> -Zac
>
> On Feb 11, 2009, at 12:10 PM, 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+
>> 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.
>>
>> -greg
>>
>> --
>> Technical Blaag at: http://blog.majesticseacreature.com
>> Non-tech stuff at: http://metametta.blogspot.com
>> "Ruby Best Practices"  Book now in O'Reilly Roughcuts:
>> http://rubybestpractices.com
>>
>
>
>



-- 
thanks,
-pate
-------------------------
   Duty makes us do things, Love make us do things well.
http://on-ruby.blogspot.com
http://eldersjournal.blogspot.com

> Now that 1.9.1 is released, hopefully people will start porting to it, 
> and 1.8 can remain stable. For the people who still need all their old 
> gems to work, there should be a stable version -- apparently, 1.8.7 
> broke a lot of things.

If it has to use parts of the new parser, can it use Ripper??

On Thu, 12 Feb 2009, M. Edward (Ed) Borasky wrote:

> I've posted my opinions on Ruby-Core, but I'll summarize them here:
>
> 1. The Ruby community should proceed with all deliberate speed towards
> ISO standardization of the language.

Yeah, look what it did to Forth.

-- Matt
It's not what I know that counts.
It's what I can remember in time to use.

On Wed, Feb 11, 2009 at 2:47 PM, Matt Lawrence <matt@technoronin.com> wrote:
> On Thu, 12 Feb 2009, M. Edward (Ed) Borasky wrote:
>
>> I've posted my opinions on Ruby-Core, but I'll summarize them here:
>>
>> 1. The Ruby community should proceed with all deliberate speed towards
>> ISO standardization of the language.
>
> Yeah, look what it did to Forth.

Don't just say it, show it.

http://vividpicture.com/aleks/atari/forth.jpg

-greg

-- 
Technical Blaag at: http://blog.majesticseacreature.com
 Non-tech stuff at: http://metametta.blogspot.com
"Ruby Best Practices"  Book now in O'Reilly Roughcuts:
http://rubybestpractices.com

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+
> 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.
> 
> -greg
> 


+1

Matt Lawrence wrote:
> On Thu, 12 Feb 2009, M. Edward (Ed) Borasky wrote:
> 
>> I've posted my opinions on Ruby-Core, but I'll summarize them here:
>>
>> 1. The Ruby community should proceed with all deliberate speed towards
>> ISO standardization of the language.
> 
> Yeah, look what it did to Forth.

The process of ANS standardization focused the Forth community and
produced a syntax and semantics that are well-regarded in today's Forth
community. I wouldn't be using Forth today if it weren't for the ANS
standard!

-- 
M. Edward (Ed) Borasky

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

On 11 Feb 2009, at 19:55, Gregory Brown wrote:
> On Wed, Feb 11, 2009 at 2:47 PM, Matt Lawrence  
> <matt@technoronin.com> wrote:
>> On Thu, 12 Feb 2009, M. Edward (Ed) Borasky wrote:
>>
>>> I've posted my opinions on Ruby-Core, but I'll summarize them here:
>>>
>>> 1. The Ruby community should proceed with all deliberate speed  
>>> towards
>>> ISO standardization of the language.
>>
>> Yeah, look what it did to Forth.
>
> Don't just say it, show it.
>
> http://vividpicture.com/aleks/atari/forth.jpg

Too many old Forth hands on here ;p

With all this back-porting it's as if the foreshadowed magnitude of  
Ruby 2.0 is making the core team nervous of turning 1.9 into a genuine  
stable branch, so instead they're forcing the stable features into 1.8  
instead. I'm sure this is a complete misreading of their intent on my  
part but it is a worrying path to be heading down.

I'll admit that so far I've not had any problems with 1.8.7 but my  
colleague Romek has been having a horrible time with its OpenSSL  
support and quite a few of the tools he's written with 1.8.6 no longer  
work. We're currently debating whether or not to bite the bullet and  
move to 1.9.1 - assuming the current crop of books are an accurate  
representation.

Anyway if I or another developer want 1.9 features and/or syntax we'll  
use 1.9 and the fact that some of us choose not to do so at this time  
is something I'd like to see respected by the core team.

+1


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason

I am not happy.

Ruby 1.8.7 and Ruby 1.8.8 are attempts to bridge the gap between 1.8.6 
and 1.9, but they change the 1.8 line in much more drastic ways that is 
warranted by a minor version number change. That's one point against them.

A similar approach in the Python community has led to 2.6, 2.7 releases 
stepping toward 3.0, but those are major release version number changes 
and they're only doing them if the community demands them. In this case, 
1.8.7 and 1.8.8 are moving forward whether the community wants them or 
not. Another point against.

Minor version releases should certainly not break things except as 
needed to fix bugs. Ruby 1.8.7 did this initially. They should not add 
entirely new APIs incompatible with other minor releases. They should 
not add new syntax incompatible with other minor releases. Ruby 1.8.7 
does the former, and 1.8.8 syntax backports will do the latter. More 
points against.

I still feel like Ruby 1.9 should have been 2.0. Then 1.8.7 could have 
been 1.9, 1.8.8 could be 1.10, and so on, and people depending on "Ruby 
1.8" to behave like "Ruby 1.8" would not be forced to upgrade.

In general, I don't have any doubt that 1.8.7 and 1.8.8 would be fine 
standalone releases, but making them be minor version number changes 
essentially forces everyone to upgrade eventually, whether they want to 
or not, since Ruby distributors generally don't expect a 0.0.x release 
to be filled with incompatible changes or additions. Ubuntu, for 
example, now installs 1.8.7 by default, so Ubuntu users are now much 
more likely to write code that doesn't work on 1.8.6.

And note also that Ruby core has only a few resources to maintain Ruby 
versions...which means the existence of 1.8.7 and plans for 1.8.8 will 
eventually force 1.8.6 to be abandoned like 1.8.5 and 1.8.4. How would 
you feel about 1.8.6 being EOLed because of 1.8.7 and 1.8.8 taking up 
resources?

- Charlie

On Wed, Feb 11, 2009 at 6:10 PM, Gregory Brown
<gregory.t.brown@gmail.com> 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+
> 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.
>
> -greg
>
Good idea Greg, now that Ruby1.9 is out I really fail to see the
advantages of this.
I am writing lots of compatibility code between 1.8.6 1.8.7 and 1.9
and that really is time not too well spent.

I would like 1.8.6-->1.8.8 so that I can just drop 1.8.7 support

1.8.7, 1.8.9 not really a strong opinion here, those could follow the
rule of dev. releases: use on own risk.
1.9 of course is great no complaints.

Cheers
Robert

On Feb 11, 2:04=A0pm, "M. Edward (Ed) Borasky" <zzn...@gmail.com> wrote:
> Matt Lawrence wrote:
> > On Thu, 12 Feb 2009, M. Edward (Ed) Borasky wrote:
>
> >> I've posted my opinions on Ruby-Core, but I'll summarize them here:
>
> >> 1. The Ruby community should proceed with all deliberate speed towards
> >> ISO standardization of the language.
>
> > Yeah, look what it did to Forth.
>
> The process of ANS standardization focused the Forth community and
> produced a syntax and semantics that are well-regarded in today's Forth
> community. I wouldn't be using Forth today if it weren't for the ANS
> standard!
>

The process of ANS standardization decimated the Forth community and
produced a syntax and semantics that are grudgingly accepted by some
in today's tiny Forth community.

He wouldn't be using Forth today if it weren't for the ANS
standard!  (A strong argument against standardization.)

[Note:  parts of this message were removed to make it a legal post.]

On Wed, Feb 11, 2009 at 12:10 PM, Gregory Brown
<gregory.t.brown@gmail.com>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+
> 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.
>
>
+1024!

Others have pointed out the folly of having a teeny version number change
carry API breaking changes.

Ruby 1.8.7 is NOT compatible with Ruby 1.8.6.

On an aside do any of the OS X users know if there's a way in Macports to
pin the version number of a package?  The whole Ruby 1.8.7 thing has made me
very paranoid of doing an errant port upgrade.

-- 
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale

On 11.02.2009 18:27, James Gray wrote:
> On Feb 11, 2009, at 11:10 AM, 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+
>> 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.
> 
> I'm bothered by the new versioning scheme.
> 
> The new releases involve big changes and even if they are fully  
> backwards compatible about what they will run, they are still creating  
> pretty big compatibility gaps.  Code using any of the new 1.8.7  
> features won't run on 1.8.6 and lower.

Well, but this is usual, isn't it?  If you want exact 1.8.6 then take 
1.8.6.  Or do you see changes in the third number as sole bug fix changes?

>  It sounds as if 1.8.8 intends  
> to take this farther, so code written to that won't work in the  
> different 1.8.7 branch or the earlier 1.8.6 and lower stuff.

But if I understand this correctly, 1.8.6 code will also run on 1.8.7 
and later.

>  Thus I  
> feel we now have three different versions of Ruby 1.8 on the table  
> (counting the not yet released 1.8.8).

That seems to be the case.  Maybe 1.8.7 should really have been 1.9.0 
but that version is taken already...  IMHO the changes in 1.9 are big 
enough to warrant a 2.x but I guess Matz et al. have put quite a bit of 
thought into the version numbers - so maybe we should hear that before 
we make any judgments about what fits in a release and what not.

Kind regards

	robert

[Note:  parts of this message were removed to make it a legal post.]

On Wed, Feb 11, 2009 at 1:42 PM, M. Edward (Ed) Borasky <zznmeb@gmail.com>wrote:

> I've posted my opinions on Ruby-Core, but I'll summarize them here:
>
> 1. The Ruby community should proceed with all deliberate speed towards
> ISO standardization of the language.


Matz and his team announced that they were beginning and effort towards this
end at RubyConf 2008.

However, I'm not sure I understand if their approach of doing this under the
aegis of (IIRC) the Linux Foundation gets us to an ISO standard, based on my
experiences of the ANSI/ISO process when I worked on standards like X3J20
for Smalltalk.


>
> 2. There are two "de facto" standards for the Ruby language at present.
>    a. Ruby 1.8.6 as documented in the Pickaxe, Second Edition
>    b. Ruby 1.9.1 as documented in "The Well-Grounded Rubyist",
>       "Programming Ruby 1.9" and "The Ruby Programming Language".
>
>   All other versions are irrelevant and a waste of precious developer
>   energy as far as I'm concerned.
>
> 3. I don't think it matters what the numbers are, but since the two "de
> facto" standard versions have designated numbers already, why not keep
> them as they are?


As others point out, there are a lot of packaging systems which make the
assumption that a minor version number change is compatible.  When the ruby
team breaks that assumption, it can cause havoc for those who install and
maintain their system with standard tools like dpkg/apt-get, ports, etc.

Some of the maintainers of packaged software don't really work with the
packages they maintain, and aren't necessarily aware of or appreciative of
philosophical differences like these. When the upstream developers break the
assumptions of the package maintainers, it can lead to as much trouble as
when the package maintainers disagree with the philosophy of the upstream
developers and do things their own way. I'm talking about what debian/ubuntu
do/did to rubygems here.



-- 
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale

2009/2/11 Rick DeNatale <rick.denatale@gmail.com>:
> Ruby 1.8.7 is NOT compatible with Ruby 1.8.6.

I've seen many people claiming this, and they might be right of
course, but no one has shown any examples yet. If it is so hard to
find 1.8.6 code that doesn't work with 1.8.7, the backward
compatibility of 1.8.7 seems to be pretty good.

Regards,
Pit

[Note:  parts of this message were removed to make it a legal post.]

On Wed, Feb 11, 2009 at 4:13 PM, Robert Klemme
<shortcutter@googlemail.com>wrote:

> On 11.02.2009 18:27, James Gray wrote:
>
>> On Feb 11, 2009, at 11:10 AM, 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+
>>> 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.
>>>
>>
>> I'm bothered by the new versioning scheme.
>>
>> The new releases involve big changes and even if they are fully  backwards
>> compatible about what they will run, they are still creating  pretty big
>> compatibility gaps.  Code using any of the new 1.8.7  features won't run on
>> 1.8.6 and lower.
>>
>
> Well, but this is usual, isn't it?  If you want exact 1.8.6 then take
> 1.8.6.  Or do you see changes in the third number as sole bug fix changes?


That's the industry practice, a minor version number change normally means
that there should be no or very little impact on the installed base of
'legacy' code.




  It sounds as if 1.8.8 intends  to take this farther, so code written to
> that won't work in the  different 1.8.7 branch or the earlier 1.8.6 and
> lower stuff.
>

But if I understand this correctly, 1.8.6 code will also run on 1.8.7 and
> later.


I must say that I'm not entirely up to date with what NOW works on 1.8.7,
the stuff which used to break, e.g. rails and many gems has been catching up
to the changes, but that is cold comfort for those who are faced with a
broken deployment and either have to back-level dependencies, or go through
a sometimes painful process of migrating  a large application from the
version of, say rails, they were using to the new one which runs on 1.8.7.

It's not so much of a problem for folks writing standalone code, or code
with a small set of dependencies, but it has, and I suspect it continues to
have, a large impact on a lot of folks trying to maintain their bread and
butter.


>
>   Thus I  feel we now have three different versions of Ruby 1.8 on the
>> table  (counting the not yet released 1.8.8).
>>
>
> That seems to be the case.  Maybe 1.8.7 should really have been 1.9.0 but
> that version is taken already...  IMHO the changes in 1.9 are big enough to
> warrant a 2.x but I guess Matz et al. have put quite a bit of thought into
> the version numbers - so maybe we should hear that before we make any
> judgments about what fits in a release and what not.
>

As I remember it, Matz didn't want to have a version number like 1.8.10, and
since there was danger of 'running out' the version numbering scheme was
changed to make 1.9.0  the 'unstable' development release, and use a teeny
number greater than or equal to 1 to indicate stability.  This was OK as it
stood, but then 1.8.7 came along and introduced incompatible changes
backported from 1.9.0.

Regardless of the percentage of gems and frameworks which have been updated
to work with 1.8.7. I still maintain that the backporting in 1.8.7 was a bad
idea, and pushing it further would compound the problem.

-- 
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale

On Feb 11, 2009, at 3:42 PM, Pit Capitain wrote:

> 2009/2/11 Rick DeNatale <rick.denatale@gmail.com>:
>> Ruby 1.8.7 is NOT compatible with Ruby 1.8.6.
>
> I've seen many people claiming this, and they might be right of
> course, but no one has shown any examples yet.

This is trivial to prove.  This code:

   Object.new.tap { |o| p o }

runs on 1.8.7 and not 1.8.6.

James Edward Gray II

Pit Capitain wrote:
> 2009/2/11 Rick DeNatale <rick.denatale@gmail.com>:
>> Ruby 1.8.7 is NOT compatible with Ruby 1.8.6.
> 
> I've seen many people claiming this, and they might be right of
> course, but no one has shown any examples yet. If it is so hard to
> find 1.8.6 code that doesn't work with 1.8.7, the backward
> compatibility of 1.8.7 seems to be pretty good.

Well, Rails. And many SWIG-based C-extensions - eg wxRuby.

But this misses the main point - that there is no assurance that code 
developed using 1.8.7 (or 1.8.8) will run on 1.8.6. And no way of 
checking, other than scrutinising the ChangeLog. This is a huge 
disservice to library authors and users.

a

[Note:  parts of this message were removed to make it a legal post.]

On Wed, Feb 11, 2009 at 4:53 PM, James Gray <james@grayproductions.net>wrote:

> On Feb 11, 2009, at 3:42 PM, Pit Capitain wrote:
>
>  2009/2/11 Rick DeNatale <rick.denatale@gmail.com>:
>>
>>> Ruby 1.8.7 is NOT compatible with Ruby 1.8.6.
>>>
>>
>> I've seen many people claiming this, and they might be right of
>> course, but no one has shown any examples yet.
>>
>
> This is trivial to prove.  This code:
>
>  Object.new.tap { |o| p o }
>
> runs on 1.8.7 and not 1.8.6.
>

True, although the real issue is that there is code which runs on 1.8.6 and
doesn't run 'correctly' on 1.8.7.

The real problem is when the semantics have changed, and this breaks
frameworks and gems and such.

-- 
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale

Le 11 f�vrier 2009 � 22:53, Alex Fenton a �crit :

> Pit Capitain wrote:
>> 2009/2/11 Rick DeNatale <rick.denatale@gmail.com>:
>>> Ruby 1.8.7 is NOT compatible with Ruby 1.8.6.
>> 
>> I've seen many people claiming this, and they might be right of
>> course, but no one has shown any examples yet. If it is so hard to
>> find 1.8.6 code that doesn't work with 1.8.7, the backward
>> compatibility of 1.8.7 seems to be pretty good.
> 
> Well, Rails. And many SWIG-based C-extensions - eg wxRuby.
> 
> But this misses the main point - that there is no assurance that code 
> developed using 1.8.7 (or 1.8.8) will run on 1.8.6. And no way of 
> checking, other than scrutinising the ChangeLog. This is a huge 
> disservice to library authors and users.

Somehow, I was wondering why the "new" code in 1.8.(7|8) isn't made
available through a library.

Something like :

require "compat-1.9"

Object.new.tap { |o| p o }

I guess that it's a lot of work if it's implemented in C, but maybe the
work that went into backporting the functionality was misdirected and
could have been more useful in doing a few ruby-written libraries to
help smoothen the transition...

My 2 euro-cents.

Fred
-- 
When you like music more than life,      something's wrong
When you start sleeping as you drive,    something's wrong
When you're favorite drink is thinner,   something's wrong
When you're proud to be a sinner...      (K's Choice, Something's wrong)

2009/2/11 Alex Fenton <alex@deleteme.pressure.to>:
> Well, Rails. And many SWIG-based C-extensions - eg wxRuby.

AFAIK 1.8.7 introduced a method that Rails was using. This could have
happened in previous Ruby upgrades as well. I don't see why this is
something special with 1.8.7.

As for the C extensions: do you have more information about what was
changed in the Ruby internals that lead to those problems?

> But this misses the main point - that there is no assurance that code
> developed using 1.8.7 (or 1.8.8) will run on 1.8.6.

Again, this is nothing special with the 1.8.7 release. It has been
like this since I'm using Ruby, which is since 2000. The important
point is that (most) 1.8.6 code still runs on 1.8.7.

The only thing I understand you having problems with is that for other
software projects you can expect that for example no new methods are
introduced between a.b.c and a.b.d, so that the Rails problem wouldn't
have occurred there. But, again, Ruby version numbers have never been
working like that. Despite this we have been able to arrive at 1.8.6,
and I still don't see what's so special with 1.8.7 that we should stop
at 1.8.6.

Regards,
Pit

2009/2/11 Rick DeNatale <rick.denatale@gmail.com>:

> True, although the real issue is that there is code which runs on 1.8.6 and
> doesn't run 'correctly' on 1.8.7.
>
> The real problem is when the semantics have changed, and this breaks
> frameworks and gems and such.

But this is because the former was consider a bug or for another
reason? For example, (taken from
http://svn.ruby-lang.org/repos/ruby/tags/v1_8_7/NEWS )

* Date.parse

    '##.##.##' (where each '#' is a digit) is now taken as 'YY.MM.DD'
    instead of 'MM.DD.YY'.  While the change may confuse you, you can
    always use Date.strptime() when you know what you are dealing
    with.

Looks like a really strange change to me. In fact, it confuses me. Ok,
I know I can use Date.strptime when I know what I'm dealing with, but
I still don't get the point.

Someone can enlighten me, please?

Regards,

Serabe

-- 
http://www.serabe.com

M. Edward (Ed) Borasky wrote:
>    All other versions are irrelevant and a waste of precious developer
>    energy as far as I'm concerned.

But what if they want to waste their energy there?

To maintain an old piece of crap like MRI cannot be nothing but boring.  Every
precious developers you can think of is precious just because he/she can create
a bright new idea. No one wants to nurse a dead-ended product.

+1 if 1.8.7 can't run 1.8.6 code. I don't so much care if they *add*
abilities to bridge to 1.9.

That said, I have a simple solution. Move to 1.9.1 as fast as your
fingers will allow. Do not pass go. Do not collect $200. Get'r done.

T.

[Note:  parts of this message were removed to make it a legal post.]

2009/2/11 Pit Capitain <pit.capitain@gmail.com>

> 2009/2/11 Rick DeNatale <rick.denatale@gmail.com>:
> > Ruby 1.8.7 is NOT compatible with Ruby 1.8.6.
>
> I've seen many people claiming this, and they might be right of
> course, but no one has shown any examples yet. If it is so hard to
> find 1.8.6 code that doesn't work with 1.8.7, the backward
> compatibility of 1.8.7 seems to be pretty good.



Requires hoe, ZenTest and 1.8.6 and 1.8.7 installed using multiruby:

git clone git://github.com/jcoglan/packr.git packr
cd packr
git co -b 3.1 origin/3.1
git co 4cc307
rake multi

This is not using any new 1.8.7 features, it's using 1.8.6 behaviour that
broke. Under 1.8.6, hashes had keys inserted in the order in which they
appear in the source, which is not true of 1.8.7. Granted, this ordering was
never explicitly intended for 1.8.x, but still it introduced major bugs in
my code. PackR still has a bug I'm unable to fix on 1.8.7, though thankfully
it's not a show-stopper, it's a nice-to-have 'bonus feature' that doesn't
work.

I for one do not want to pull updates to ruby1.8 from my package manager and
have even more of my code break, esp. as I maintain various libraries and
it's hell having to explain to people that my code is broken because their
package manager is not fine-grained enough and they need to install stuff
from source. I expect stuff to not be 100% on 1.9, but my experience so far
is that 1.9 has caused me fewer and more easily fixable bugs than 1.8.7.

[climbs to the top of the pile-up]

This is like an argument about what to do with the tricycle you rode as 
a kid.  Sure you may disagree about the current condition of the 
tricycle, but really, who cares?  You are grown up now.  You can avoid 
the issue entirely if you just stop riding the tricycle.
-- 
Posted via http://www.ruby-forum.com/.

F. Senault wrote:
> Le 11 f�vrier 2009 � 22:53, Alex Fenton a �crit :
>   
>> But this misses the main point - that there is no assurance that code 
>> developed using 1.8.7 (or 1.8.8) will run on 1.8.6. And no way of 
>> checking, other than scrutinising the ChangeLog. This is a huge 
>> disservice to library authors and users.
>>     
> Something like :
>
> require "compat-1.9"
>
> Object.new.tap { |o| p o }
>
> I guess that it's a lot of work if it's implemented in C,

I don't see why it would be -- wouldn't be the first C extension -- but 
it's possbile I just don't understand the issue.

Regardless, many of these are just trivial.

class Object
  def tap
    yield self
    self
  end
end

class Symbol
  def to_proc
    proc {|x| self.send(x) }
  end
end

There are a few, like public_send (which I really should be using there) 
-- actually missing from 1.8.7, but I've actually got my own implemented 
somewhere. In fact, the above don't really even need to be aware of 
version numbers -- just something like:

unless Object.new.respond_to? :tap
  class Object
    def tap
...

unless :to_proc.respond_to? :to_proc
  class Symbol
    def to_proc
...

That would allow such libraries to be distributed as gems, and they'd do 
no harm if run under 1.9 -- if there's already a C version in place, use 
that, otherwise, add our own ruby version.

In fact, this is already how I develop things. I test on 1.8.7 and 
1.9.1, but anything I build should work on 1.8.6 as well -- so far, 
there's been nothing added to 1.8.7 that can't be added to 1.8.6 as 
well, using plain old Ruby.

On Wed, Feb 11, 2009 at 6:44 PM, Mike Gold <mike.gold.4433@gmail.com> wrote:
> [climbs to the top of the pile-up]
>
> This is like an argument about what to do with the tricycle you rode as
> a kid.  Sure you may disagree about the current condition of the
> tricycle, but really, who cares?  You are grown up now.  You can avoid
> the issue entirely if you just stop riding the tricycle.

You're right. So then perhaps the whole 1.8 series should be
end-of-lifed.  I'd be fine with that.
But Ruby 1.8.7 is more like thaking the old tricycle out and putting a
car engine on it.

Cute, but not a very useful tricycle or car at that point.

-greg

-- 
Technical Blaag at: http://blog.majesticseacreature.com
 Non-tech stuff at: http://metametta.blogspot.com
"Ruby Best Practices"  Book now in O'Reilly Roughcuts:
http://rubybestpractices.com

On Wed, Feb 11, 2009 at 12:53 PM,  <w_a_x_man@yahoo.com> wrote:
> The process of ANS standardization decimated the Forth community

I don't think that's the case. What "decimated" the Forth community
was the emergence of microprocessors powerful enough to run languages
other than Forth and usable optimizing compilers for the C language
for less-powerful microprocessors that previously could only be
effectively programmed in Forth. Yes, the standardization process was
contentious, and I have no doubt Ruby's will be as well. But I think
it's something the community needs to do. Maybe the outcome of this
thread / discussion will be to establish an on-line "standards
committee".

-- 
M. Edward (Ed) Borasky

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

Charles Oliver Nutter wrote:
> And note also that Ruby core has only a few resources to maintain Ruby
> versions...which means the existence of 1.8.7 and plans for 1.8.8 will
> eventually force 1.8.6 to be abandoned like 1.8.5 and 1.8.4. How would
> you feel about 1.8.6 being EOLed because of 1.8.7 and 1.8.8 taking up
> resources?

This can of course be avoided if someone else follows me to continue supporting
1.8.6.  Merging back upper stream changes into 1.8.6 is actually easy; it is an
automated process and you do not have to write C until "svn merge" conflicts
something.  The harder part is to decide which one to merge.

On Wed, Feb 11, 2009 at 3:03 PM, Trans <transfire@gmail.com> wrote:
> +1 if 1.8.7 can't run 1.8.6 code. I don't so much care if they *add*
> abilities to bridge to 1.9.
>
> That said, I have a simple solution. Move to 1.9.1 as fast as your
> fingers will allow. Do not pass go. Do not collect $200. Get'r done.
>
> T.
>
>

That's exactly *my* plan, but I don't have legacy Rails apps or large
RSpec test suites to maintain.


-- 
M. Edward (Ed) Borasky

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

Hi Greg et al,

I'd really love to have only 1.8.6 (or compatible) then 1.9.x.

Having more seems like a waste of efforts and will (I'm afraid) make
it more difficult to ensure various plugins/gems do work properly. As
a consequence the ruby/rails/merb etc applications maintainers will
meet more trouble.

+1 for 1.8.x staying compatible with 1.8.6, absolutely.

-- Thibaut

On 11/02/2009, Charles Oliver Nutter <charles.nutter@sun.com> wrote:

>  Minor version releases should certainly not break things except as needed
> to fix bugs. Ruby 1.8.7 did this initially. They should not add entirely new
> APIs incompatible with other minor releases. They should not add new syntax
> incompatible with other minor releases. Ruby 1.8.7 does the former, and
> 1.8.8 syntax backports will do the latter. More points against.
>
>  I still feel like Ruby 1.9 should have been 2.0. Then 1.8.7 could have been
> 1.9, 1.8.8 could be 1.10, and so on, and people depending on "Ruby 1.8" to
> behave like "Ruby 1.8" would not be forced to upgrade.
>
>  In general, I don't have any doubt that 1.8.7 and 1.8.8 would be fine
> standalone releases, but making them be minor version number changes
> essentially forces everyone to upgrade eventually, whether they want to or
> not, since Ruby distributors generally don't expect a 0.0.x release to be
> filled with incompatible changes or additions. Ubuntu, for example, now
> installs 1.8.7 by default, so Ubuntu users are now much more likely to write
> code that doesn't work on 1.8.6.

+1

On Wed, Feb 11, 2009 at 5:03 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
> On 11/02/2009, Charles Oliver Nutter <charles.nutter@sun.com> wrote:
>>  In general, I don't have any doubt that 1.8.7 and 1.8.8 would be fine
>> standalone releases, but making them be minor version number changes
>> essentially forces everyone to upgrade eventually, whether they want to or
>> not, since Ruby distributors generally don't expect a 0.0.x release to be
>> filled with incompatible changes or additions. Ubuntu, for example, now
>> installs 1.8.7 by default, so Ubuntu users are now much more likely to write
>> code that doesn't work on 1.8.6.
>
> +1

I haven't checked Fedora recently, but openSUSE 11.1 ships Ruby 1.8.7 as well.
-- 
M. Edward (Ed) Borasky

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

On 11/02/2009, Urabe Shyouhei <shyouhei@ruby-lang.org> wrote:
> M. Edward (Ed) Borasky wrote:
>
> >    All other versions are irrelevant and a waste of precious developer
>  >    energy as far as I'm concerned.
>
>
> But what if they want to waste their energy there?
>
>  To maintain an old piece of crap like MRI cannot be nothing but boring.  Every
>  precious developers you can think of is precious just because he/she can create
>  a bright new idea. No one wants to nurse a dead-ended product.

That's completely fine but then mark the bright new idea as such, not
as a version of a dead-end product. It will do good service to both
the bright new idea and the dead-end product if they are labeled
correctly.

Thanks

Michal

Pit Capitain wrote:

> AFAIK 1.8.7 introduced a method that Rails was using. This could have
> happened in previous Ruby upgrades as well. I don't see why this is
> something special with 1.8.7.


That's the point: library authors should be able to write against a 
'stable' version of the language, without fearing that a Ruby branch 
maintainer is going to happen to fancy to add a clashing method.

As a library author, it's fair to ask me to track pre-release versions 
of 1.9, if I want to ensure timely compatibility with that. But it's not 
reasonable to ask me to track changes on a 'stable' branch.


> As for the C extensions: do you have more information about what was
> changed in the Ruby internals that lead to those problems?

http://sourceforge.net/tracker2/?func=detail&aid=2034216&group_id=1645&atid=101645

>> But this misses the main point - that there is no assurance that code
>> developed using 1.8.7 (or 1.8.8) will run on 1.8.6.
> 
> Again, this is nothing special with the 1.8.7 release. It has been
> like this since I'm using Ruby, which is since 2000. The important
> point is that (most) 1.8.6 code still runs on 1.8.7.

A folly repeated is not a folly reduced. I've suffered from this before 
1.8.5 -> 1.8.6, and been critical of it before.

I guess that 1.8.7 has just happened to make the silliness of adding a 
random pot-pourri of features more apparent to more people.

alex

Urabe Shyouhei wrote:
> M. Edward (Ed) Borasky wrote:
>>    All other versions are irrelevant and a waste of precious developer
>>    energy as far as I'm concerned.
> 
> But what if they want to waste their energy there?

Then they have picked the wrong place for their energies. People should 
be branch maintainer because they have pride in good engineering, not to 
acquire a private laboratory for what they think are 'cool' features.

> To maintain an old piece of crap like MRI cannot be nothing but boring.  Every
> precious developers you can think of is precious just because he/she can create
> a bright new idea. No one wants to nurse a dead-ended product.

People - including me - do, on many open-source projects. Of course it 
is a bit boring to have to work with old structures, when the future can 
be seen. But people do so because they see it's important work to give 
confidence in the broader project.

If someone thinks it's *so* boring, then they should work on the 
bleeding edge, not become "stable" maintainer. I'd rather 1.8 stagnate 
than change so randomly.

a

From: "Rick DeNatale" <rick.denatale@gmail.com>
> 
> As I remember it, Matz didn't want to have a version number like 1.8.10

For what it's worth, my recollection is that matz wasn't
_conceptually_ opposed to it, but rather it was not considered
acceptable to break the existing code in the field which performed
version checks based on string compares:

>> "1.8.9" > "1.8.8"
=> true

>> "1.8.10" > "1.8.9"
=> false


Regards,

Bill

Bill Kelly wrote:
> 
> From: "Rick DeNatale" <rick.denatale@gmail.com>
>>
>> As I remember it, Matz didn't want to have a version number like 1.8.10
> 
> For what it's worth, my recollection is that matz wasn't
> _conceptually_ opposed to it, but rather it was not considered
> acceptable to break the existing code in the field which performed
> version checks based on string compares:
> 
>>> "1.8.9" > "1.8.8"
> => true
> 
>>> "1.8.10" > "1.8.9"
> => false

I remember that... did anyone ever suggest other number bases?

irb(main):001:0> "1.8.9" > "1.8.8"
=> true
irb(main):002:0> "1.8.A" > "1.8.8"
=> true

Nah, too weird!

-- 
       vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407

Alex Fenton wrote:
>> But what if they want to waste their energy there?
> 
> Then they have picked the wrong place for their energies. People should
> be branch maintainer because they have pride in good engineering, not to
> acquire a private laboratory for what they think are 'cool' features.

I don't intend to attack but for instance _why hasn't been touching his yaml
stdlib for years, in spite of yaml bugs continuously reported.  If _why had
such pride you say, can that be possible?

Again, I'm not attacking _why.  It's a nature of geek being that they get
interested in a new thing than old ones.  Some people like you may be able to
maintain existing codes, but not everyone.  Do not expect others to behave as
you do.

>> To maintain an old piece of crap like MRI cannot be nothing but
>> boring.  Every
>> precious developers you can think of is precious just because he/she
>> can create
>> a bright new idea. No one wants to nurse a dead-ended product.
> 
> People - including me - do, on many open-source projects. Of course it
> is a bit boring to have to work with old structures, when the future can
> be seen. But people do so because they see it's important work to give
> confidence in the broader project.

Of course not everyone ignore bugs.  In fact most bugfixes aren't possible
without many helps of core developers.  It's hence important for us not to
prevent core people to pray with Ruby.  Bugfixes and new features are both
sourced from a developer brain and are dripped into Ruby 1.8 source code
altogether. To filter bugfixes only isn't easy, palming off that job to them
should drastically decrease their amount of output.  That shouldn't make us happy.

> If someone thinks it's *so* boring, then they should work on the
> bleeding edge, not become "stable" maintainer. I'd rather 1.8 stagnate
> than change so randomly.

I suspect that's why no one but me is touching 1.8.6 now.

Urabe Shyouhei wrote:

> I don't intend to attack but for instance _why hasn't been touching his yaml
> stdlib for years, in spite of yaml bugs continuously reported.  If _why had
> such pride you say, can that be possible?

+1

> Again, I'm not attacking _why.  It's a nature of geek being that they get
> interested in a new thing than old ones.  Some people like you may be able to
> maintain existing codes, but not everyone.  Do not expect others to behave as
> you do.

I expect people to unit test their libraries and leave them open for others to 
fix. YAML can't recover from syntax errors, can't accurately report them, and 
experiences a stray pointer bug when it tries. Yes the lexer is awesome, but 
libyaml is riiiight around the corner...

> I suspect that's why no one but me is touching 1.8.6 now.

I do 1.8.6, and so does my shop.

Joel VanderWerf wrote:
> Bill Kelly wrote:
>>
>> From: "Rick DeNatale" <rick.denatale@gmail.com>
>>>
>>> As I remember it, Matz didn't want to have a version number like 1.8.10
>>
>> For what it's worth, my recollection is that matz wasn't
>> _conceptually_ opposed to it, but rather it was not considered
>> acceptable to break the existing code in the field which performed
>> version checks based on string compares:
>>
>>>> "1.8.9" > "1.8.8"
>> => true
>>
>>>> "1.8.10" > "1.8.9"
>> => false
>
> I remember that... did anyone ever suggest other number bases?
>
> irb(main):001:0> "1.8.9" > "1.8.8"
> => true
> irb(main):002:0> "1.8.A" > "1.8.8"
> => true
>
> Nah, too weird!
>

I was looking at Erlang the other day.
On the front page of erlang.org:

"Erlang/OTP R12B-5 released*"*



-Justin

Gregory Brown wrote:
> I am setting up two threads
...
> 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'.

I think it's too late to go back now, but +1 to wishing 1.8.7 had never 
existed. It causes all sorts of confusion even on this mailing list as 
to what features do or do not exist in ruby 1.8, and gives admins an 
unnecessary dilemma: upgrade all production boxes to new and relatively 
untested code which may break existing applications? Or suffer the 
complaints from new applications which start to rely on the new 
features?

This was all handled much better in the 1.6 -> 1.8 transition.

* 1.6 was stable
* 1.7 was developmental, and added a bunch of features
* finally it was released as 1.8
* there was no meddling with 1.6
* A separate "shim" library was released which included a number of 
useful new features from 1.8 (e.g. StringIO), which allowed some code 
written using 1.8 features to run under 1.6, thus extending the lifetime 
of 1.6

Under this model: 1.9 would have been experimental, it would have been 
released eventually as 1.10 (or as 2.0, I don't care). 1.8 would have 
been a stable production branch, and for those people who wanted 
1.10/2.0 features, there would be an optional compatibility library.

As for numbering, it's not so important, but the current scheme is silly 
and appears to be based on an irrational fear of exceeding 1.9. AFAICT, 
this is either because the string "1.10" doesn't sort after "1.9", or 
because 2.0 would somehow imply the language is especially "blessed" or 
"finalised".

On that basis, 2.0 will never be released. IMO, YARV was a big enough 
change to warrant a new major number. If you want to see numbering done 
properly, look at FreeBSD's release process.

Anyway, I look forward to running ruby version 1.9.9.9 in future years 
:-)
-- 
Posted via http://www.ruby-forum.com/.

Bill Kelly wrote:
> 
> From: "Rick DeNatale" <rick.denatale@gmail.com>
>>
>> As I remember it, Matz didn't want to have a version number like 1.8.10
> 
> For what it's worth, my recollection is that matz wasn't
> _conceptually_ opposed to it, but rather it was not considered
> acceptable to break the existing code in the field which performed
> version checks based on string compares:
> 
>>> "1.8.9" > "1.8.8"
> => true
> 
>>> "1.8.10" > "1.8.9"
> => false

I remember the discussions. I stand by my assertion that this is a bug.

- Charlie

In article <Y2Ekl.10025$cg.1125@newsfe24.ams2>,
Alex Fenton  <alex@deleteme.pressure.to> wrote:
>last night, and in particular Akinori MUSHA's statement:
>
>"Yes.  Backporting syntactic changes is a big part of the plan for ruby
>1.8.8"

It boggles the mind to read that. I have an enormous respect for you
Akinori-san for both your FreeBSD and Ruby work but that's poppycock.

>Luckily I was in bed else I'd have fallen off my chair. This seems to me 
>the most bonkers development plan I've seen in a long while.
>
>Stable releases are meant to be *stable*; minor point releases are meant 
>to be *API compatible*, backwards and forwards. I can't think of any 
>other serious open-source project that would even contemplate adding 
>random bits of syntax and API calls in minor releases.

+1000

I feel 1.8.7 is the biggest mistake the Ruby developers have made, it muddies
the water about what are 1.8 and 1.9 (as if the problem about 1.9 not being
ruby2 or rite or whatever it is called was not enough!), don't encourage
people to move over to 1.9 at all.

I also think this is an software engineering mistake as well. You *never*
introduce API or language changes in a stable branch, ever. Worse, it was done
in a *minor* revision. What are you guys smokin'?

We don't need any glibc-like crazyness in Ruby, thanks. It is already
difficult enough to advocate Ruby over Python already with the almost non
existent Unicode/UTF-8 support (and quirky when something exist)...

I also think m17n is way too complicated in 1.9 but that's another windmill to
fight for.

>I expressed the same opinion at length and with some fervour regarding 
>the release of 1.8.7: http://www.ruby-forum.com/topic/150251#663291

So did I, several times.

Sorry for ranting but seeing my favorite language go these ways is taking on
me.
-- 
Ollivier ROBERT -=- CND/COE/VI/SQ -=- EUROCONTROL
Systems Quality & Support

In article <deb2337a0902111303o7a281d6bw1b7368db82b83864@mail.gmail.com>,
Rick DeNatale  <rick.denatale@gmail.com> wrote:
>On an aside do any of the OS X users know if there's a way in Macports to
>pin the version number of a package?  The whole Ruby 1.8.7 thing has made me
>very paranoid of doing an errant port upgrade.

Following a ticket I opened a few weeks ago, someone has created a ruby186
port.
-- 
Ollivier ROBERT -=- CND/COE/VI/SQ -=- EUROCONTROL
Systems Quality & Support

On Feb 12, 4:21=A0am, Charles Oliver Nutter <charles.nut...@sun.com>
wrote:
> Bill Kelly wrote:
>
> > From: "Rick DeNatale" <rick.denat...@gmail.com>
>
> >> As I remember it, Matz didn't want to have a version number like 1.8.1=
0
>
> > For what it's worth, my recollection is that matz wasn't
> > _conceptually_ opposed to it, but rather it was not considered
> > acceptable to break the existing code in the field which performed
> > version checks based on string compares:
>
> >>> "1.8.9" > "1.8.8"
> > =3D> true
>
> >>> "1.8.10" > "1.8.9"
> > =3D> false
>
> I remember the discussions. I stand by my assertion that this is a bug.

I don't know about the discussions relating to this behavior, but I
find it dismaying that anyone would seriously say that this isn't
desired string comparison behavior. I mean, these are *strings*, not
anything special. They just happen to contain a certain pattern of
characters.

Or maybe you meant the bug was that people were comparing strings at
all, which is understandable (though a strange word choice).

Maybe we should start up the Perl v-string[1] debates in the Ruby
community. Actually, if Ruby core (or stdlib) had v-strings, that
would be a part of rubygems that could by set free from its cold, dark
p4 prison.


[1]: For a good time: http://search.cpan.org/~ferreira/Data-VString-0.00000=
4/lib/Data/VString.pm

--
-yossef

Le 12 f�vrier � 15:25, Yossef Mendelssohn a �crit :

> I mean, these are *strings*, not anything special. They just happen 
> to contain a certain pattern of characters.

Any Ruby string can become special :

>> RUBY_VERSION = RUBY_VERSION.dup
(irb):5: warning: already initialized constant RUBY_VERSION
=> "1.8.6"
>> class <<RUBY_VERSION ; def <=>(b)
>>    self.split(/\./).collect { |x| x.to_i } <=> b.split(/\./).collect { |x| x.to_i }
>>    end ; end
=> nil
>> RUBY_VERSION.freeze
=> "1.8.6"
>> RUBY_VERSION < '1.8.10'
=> true

But not '1.8.10' > RUBY_VERSION, alas !

:)

Fred
-- 
The above also applies to "true" and "false" tests: there can be no
absolute truth, only subjective reality as perceived from an
existentialist paradigm.
                      (Tanuki in the SDM, on politically-correct coding)

2009/2/11 James Gray <james@grayproductions.net>:
> On Feb 11, 2009, at 3:42 PM, Pit Capitain wrote:
>
>> 2009/2/11 Rick DeNatale <rick.denatale@gmail.com>:
>>>
>>> Ruby 1.8.7 is NOT compatible with Ruby 1.8.6.
>>
>> I've seen many people claiming this, and they might be right of
>> course, but no one has shown any examples yet.
>
> This is trivial to prove.  This code:
>
>  Object.new.tap { |o| p o }
>
> runs on 1.8.7 and not 1.8.6.

1.8.x releases always introduced new methods.
If Ruby releases were done how the mob here wants
them, we wouldn't have a single new method since
1.8.0 was released in 2003.

Important is backwards compatibility and Ruby 1.8.7
is backwards compatible. Nobody so far has shown
where 1.8.7 is not backwards compatible.

That Rails broke was their own fault. They extend core
classes, so clashes are to be expected. If they had
tested with an 1.8.7 release candidate, I'm sure they
could have worked out a solution with the 1.8 maintainers.

Stefan

Stefan Lang wrote:

> 1.8.x releases always introduced new methods.
> If Ruby releases were done how the mob here wants
> them, we wouldn't have a single new method since
> 1.8.0 was released in 2003.

What a great way to lead people into your viewpoint!

> Important is backwards compatibility and Ruby 1.8.7
> is backwards compatible. Nobody so far has shown
> where 1.8.7 is not backwards compatible.

require 'rubynode'

-- 
   Phlip

2009/2/12 Phlip <phlip2005@gmail.com>:

>> Important is backwards compatibility and Ruby 1.8.7
>> is backwards compatible. Nobody so far has shown
>> where 1.8.7 is not backwards compatible.
>
> require 'rubynode'

From http://rubynode.rubyforge.org/:
  "RubyNode is a library that allows read only access to Ruby's
  internal NODE structure."

It's cool that such libraries exist, but AFAIK MRI's
internal AST is  not part of its public API, much
less part of Ruby 1.8, the language.

Stefan

[Note:  parts of this message were removed to make it a legal post.]

>
>
> Important is backwards compatibility and Ruby 1.8.7
> is backwards compatible. Nobody so far has shown
> where 1.8.7 is not backwards compatible.



See my earlier demonstration:

git clone git://github.com/jcoglan/packr.git packr
cd packr
git co -b 3.1 origin/3.1
git co 4cc307
rake multi

No monkey-patching on my part, just existing 1.8.6 behaviour that changed in
1.8.7. I'm all for additions, as long as established behaviour is stable.
Additions should not break existing code if you're not monkey patching.

@_why I'm not interested in joining a mob and I'm not going to be mad at
Matz et al if they disagree with me. Just responding to a question, hope
none of this appears mob-like.

On Fri, 13 Feb 2009, Stefan Lang wrote:

> 2009/2/11 James Gray <james@grayproductions.net>:
>> On Feb 11, 2009, at 3:42 PM, Pit Capitain wrote:
>>
>>> 2009/2/11 Rick DeNatale <rick.denatale@gmail.com>:
>>>>
>>>> Ruby 1.8.7 is NOT compatible with Ruby 1.8.6.
>>>
>>> I've seen many people claiming this, and they might be right of
>>> course, but no one has shown any examples yet.
>>
>> This is trivial to prove.  This code:
>>
>>  Object.new.tap { |o| p o }
>>
>> runs on 1.8.7 and not 1.8.6.
>
> 1.8.x releases always introduced new methods.
> If Ruby releases were done how the mob here wants
> them, we wouldn't have a single new method since
> 1.8.0 was released in 2003.

There's no mob. I wish people would stop using that word in this
thread. These are, to a large extent, friends of mine, and friends of
the core team members, discussing an exceptionally important Ruby
issue with ardency but with collegiality.

Much, much more has been said about the issues involved in the recent
version policy than that it's bad to introduce any new methods in
teeny versions (and that, as far as I can see, has *not* been said).

My main problem with it is that, while I understand the idea of 1.8.7
and 1.8.8 as stepping stones to 1.9.1, I don't think we need any
stepping stones. I've been learning 1.9 pretty intensely over the past
year, and I have never felt the need to have a 1.8 version that had
1.9 features. 1.9 has kept me quite busy.

I also love 1.8.6, and while I think a lot of 1.9 features are great,
I've never felt like I can't go another day (week, month, whatever)
without them.

So the whole backporting thing has been a puzzle to me. I think, in
any case, that there's no one thing (1.8.7 not running 1.8.6 code; 
1.8.x ceasing to mean what a.b.x has generally meant in the past;
1.8.>6 leading to more, rather than less, trepidation about moving to
1.9; the issues with non-MRI implementations that Charlie and Evan
have talked about, etc.) responsible for the misgivings. It's a kind
of perfect storm of all these things.

I don't see any long-term way out of it except to focus on the move to
1.9.1. I don't mean that as a repudiation of anyone's work. It's my
assessment of where things stand, however they got there.


David

-- 
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2)

http://www.wishsight.com => Independent, social wishlist management!

2009/2/12 James Coglan <jcoglan@googlemail.com>:
>>
>>
>> Important is backwards compatibility and Ruby 1.8.7
>> is backwards compatible. Nobody so far has shown
>> where 1.8.7 is not backwards compatible.
>
>
>
> See my earlier demonstration:
>
> git clone git://github.com/jcoglan/packr.git packr
> cd packr
> git co -b 3.1 origin/3.1
> git co 4cc307
> rake multi
>
> No monkey-patching on my part, just existing 1.8.6 behaviour that changed in
> 1.8.7. I'm all for additions, as long as established behaviour is stable.
> Additions should not break existing code if you're not monkey patching.

It would be helpful to see exactly what fails.

Stefan

On Fri, 13 Feb 2009, David A. Black wrote:

> Much, much more has been said about the issues involved in the recent
> version policy than that it's bad to introduce any new methods in
> teeny versions (and that, as far as I can see, has *not* been said).

A followup to this:

I think there are two important points to keep in mind. First, it's a
matter of degree, not kind. In other words, no one is saying that
1.8.7 should be indistinguishable from 1.8.6. It's more the quantity
of change that's at issue. Here's a very crude metric, showing the
results of instance_methods(false) for various classes and modules
across three 1.8 versions:

1.8.2
String: 83
Array: 71
Hash: 45
Range: 15
Enumerable: 22

1.8.6
String: 83
Array: 71
Hash: 45
Range: 15
Enumerable: 22

1.8.7
String: 91
Array: 83
Hash: 47
Range: 15
Enumerable: 43

(Gotta love Range :-)

Of course there's no cut-off point where it ceases to be good, or
whatever. It's a matter of judgment.

The second important point is that it's not so much a matter of 1.8.7
not running 1.8.6 code, as the degree to which people expect teeny
versions to behave the way they always have -- and that means, in the
main, developing 1.8.7 code and expecting no more than a few bug-fixes
and maybe the necessity to shim a couple of methods when running it on
1.8.6 installations.

I don't think there's any question about the fact that 1.8.7 redefined
the teeny method semantics, and that it all goes back to the 1.10
issue. And of course the numbering is arbitrary and human-made, and a
given sequence of digits isn't inherently better or worse than another
sequence. It's about expectations and how the changes, once made, play
out.


David

-- 
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2)

http://www.wishsight.com => Independent, social wishlist management!

[Note:  parts of this message were removed to make it a legal post.]

>
>
> > See my earlier demonstration:
> >
> > git clone git://github.com/jcoglan/packr.git packr
> > cd packr
> > git co -b 3.1 origin/3.1
> > git co 4cc307
> > rake multi
> >
> > No monkey-patching on my part, just existing 1.8.6 behaviour that changed
> in
> > 1.8.7. I'm all for additions, as long as established behaviour is stable.
> > Additions should not break existing code if you're not monkey patching.
>
> It would be helpful to see exactly what fails.



The cause of the failing tests is a change to Hash ordering between
versions. See the fix patch for a better idea:

http://github.com/jcoglan/packr/commit/9ece59428bbd1bfd497b45a2ae4de2d163a24849

2009/2/12 James Coglan <jcoglan@googlemail.com>:
>>
>>
>> > See my earlier demonstration:
>> >
>> > git clone git://github.com/jcoglan/packr.git packr
>> > cd packr
>> > git co -b 3.1 origin/3.1
>> > git co 4cc307
>> > rake multi
>> >
>> > No monkey-patching on my part, just existing 1.8.6 behaviour that changed
>> in
>> > 1.8.7. I'm all for additions, as long as established behaviour is stable.
>> > Additions should not break existing code if you're not monkey patching.
>>
>> It would be helpful to see exactly what fails.
>
>
>
> The cause of the failing tests is a change to Hash ordering between
> versions. See the fix patch for a better idea:
>
> http://github.com/jcoglan/packr/commit/9ece59428bbd1bfd497b45a2ae4de2d163a24849
>

What do you mean with "Hash ordering"?
An order for Hash instances? Hash doesn't define a <=> method.
Or iteration order of Hash elements? That wasn't defined
in 1.8.6 (I don't know if it is in 1.8.7).

Stefan

	 Engine Yard is willing to step up as the official maintainer of  
ruby1.8.6. We can provide the right amount of human resources as well  
as server and QA resources with automated CI running the rubyspecs.

	I feel that it is very important to keep a stable ruby 1.8.6 lineage  
for some time to come.

	Matz has stated that he is willing to pass the torch on maintenance  
of ruby1.8.6 and we would like to step up to the plate for the whole  
ruby community. Please respond here if you think Engine yard would  
make good maintainers of the ruby1.8.6 lineage

Thanks

Ezra Zygmuntowicz
ez@engineyard.com

Ezra Zygmuntowicz wrote:
>
>      Engine Yard is willing to step up as the official maintainer of 
> ruby1.8.6. We can provide the right amount of human resources as well 
> as server and QA resources with automated CI running the rubyspecs.
>
>     I feel that it is very important to keep a stable ruby 1.8.6 
> lineage for some time to come.
>
>     Matz has stated that he is willing to pass the torch on 
> maintenance of ruby1.8.6 and we would like to step up to the plate for 
> the whole ruby community. Please respond here if you think Engine yard 
> would make good maintainers of the ruby1.8.6 lineage
>
> Thanks
>
> Ezra Zygmuntowicz
> ez@engineyard.com
>
>
>
>
>
+1.

-- 
 Ola Bini (http://olabini.com) 
 Ioke creator (http://ioke.org)
 JRuby Core Developer (http://jruby.org)
 Developer, ThoughtWorks Studios (http://studios.thoughtworks.com)
 Practical JRuby on Rails (http://apress.com/book/view/9781590598818)

 "Yields falsehood when quined" yields falsehood when quined.

On Thu, Feb 12, 2009 at 12:22 PM, Ezra Zygmuntowicz <ezmobius@gmail.com> wrote:
>
>         Engine Yard is willing to step up as the official maintainer of
> ruby1.8.6. We can provide the right amount of human resources as well as
> server and QA resources with automated CI running the rubyspecs.
>
>        I feel that it is very important to keep a stable ruby 1.8.6 lineage
> for some time to come.
>
>        Matz has stated that he is willing to pass the torch on maintenance
> of ruby1.8.6 and we would like to step up to the plate for the whole ruby
> community. Please respond here if you think Engine yard would make good
> maintainers of the ruby1.8.6 lineage

I think that's a great idea.  Restating what I said on ruby-core:

This would give those of us who need a stable legacy 1.8 to follow a
place to look for bug fixes and stablizations.   We would be free to
choose whether we want to support this sort of next-generation Ruby
1.8 that ruby-core provides, and no matter what side of the fence
you're on, you can always follow Ruby 1.9.1 as well if you wish.  In
my case, I'd likely be supporting EYRuby (or whatever you'll call it),
and Ruby 1.9.1 from the core team for my projects.  Others could mix
and match as they please, but they will have the luxury of not having
to dig down into a single release of a branch that has diverged from
it.  That's cool all around.

Just one question:  Have you though about version numbering / naming
schemes yet?

-greg

-- 
Technical Blaag at: http://blog.majesticseacreature.com
 Non-tech stuff at: http://metametta.blogspot.com
"Ruby Best Practices"  Book now in O'Reilly Roughcuts:
http://rubybestpractices.com

[Note:  parts of this message were removed to make it a legal post.]

On Thu, Feb 12, 2009 at 12:22 PM, Ezra Zygmuntowicz <ezmobius@gmail.com>wrote:

>
>         Engine Yard is willing to step up as the official maintainer of
> ruby1.8.6. We can provide the right amount of human resources as well as
> server and QA resources with automated CI running the rubyspecs.
>
>        I feel that it is very important to keep a stable ruby 1.8.6 lineage
> for some time to come.
>
>        Matz has stated that he is willing to pass the torch on maintenance
> of ruby1.8.6 and we would like to step up to the plate for the whole ruby
> community. Please respond here if you think Engine yard would make good
> maintainers of the ruby1.8.6 lineage
>
>
+1

Although, I'm at a loss as to what you'd use for the version number on the
first maintenance release.


-- 
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale

On Thu, Feb 12, 2009 at 12:36 PM, Rick DeNatale <rick.denatale@gmail.com> wrote:
> On Thu, Feb 12, 2009 at 12:22 PM, Ezra Zygmuntowicz <ezmobius@gmail.com>wrote:
>
>>
>>         Engine Yard is willing to step up as the official maintainer of
>> ruby1.8.6. We can provide the right amount of human resources as well as
>> server and QA resources with automated CI running the rubyspecs.

> Although, I'm at a loss as to what you'd use for the version number on the
> first maintenance release.

Just a thought...

RUBY_VERSION #=> "1.8.6"
EY_RUBY_VERSION #=> "1.0.0"

-greg

On Thu, Feb 12, 2009 at 10:22 AM, Ezra Zygmuntowicz <ezmobius@gmail.com> wrote:
>
>         Engine Yard is willing to step up as the official maintainer of
> ruby1.8.6. We can provide the right amount of human resources as well as
> server and QA resources with automated CI running the rubyspecs.
>
>        I feel that it is very important to keep a stable ruby 1.8.6 lineage
> for some time to come.
>
>        Matz has stated that he is willing to pass the torch on maintenance
> of ruby1.8.6 and we would like to step up to the plate for the whole ruby
> community. Please respond here if you think Engine yard would make good
> maintainers of the ruby1.8.6 lineage

Ezra, this would be an incredible step.  Please, please do it.



>
> Thanks
>
> Ezra Zygmuntowicz
> ez@engineyard.com
>
>
>
>
>



-- 
thanks,
-pate
-------------------------
   Duty makes us do things, Love make us do things well.
http://on-ruby.blogspot.com
http://eldersjournal.blogspot.com

[Note:  parts of this message were removed to make it a legal post.]

>
>
>
> What do you mean with "Hash ordering"?
> An order for Hash instances? Hash doesn't define a <=> method.
> Or iteration order of Hash elements? That wasn't defined
> in 1.8.6 (I don't know if it is in 1.8.7).



In 1.8.6, iteration order would be the same as the order that the keys
appear in the source. 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).

On Feb 12, 2009, at 11:36 AM, Rick DeNatale wrote:

> Although, I'm at a loss as to what you'd use for the version number  
> on the first maintenance release.

1.8.6.1 perhaps?  It still sorts well.

James Edward Gray II

Rick DeNatale wrote:
> On Thu, Feb 12, 2009 at 12:22 PM, Ezra Zygmuntowicz <ezmobius@gmail.com>wrote:
>
>   
>>         Engine Yard is willing to step up as the official maintainer of
>> ruby1.8.6. We can provide the right amount of human resources as well as
>> server and QA resources with automated CI running the rubyspecs.
>>
>>        I feel that it is very important to keep a stable ruby 1.8.6 lineage
>> for some time to come.
>>
>>        Matz has stated that he is willing to pass the torch on maintenance
>> of ruby1.8.6 and we would like to step up to the plate for the whole ruby
>> community. Please respond here if you think Engine yard would make good
>> maintainers of the ruby1.8.6 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?

-- 
 Ola Bini (http://olabini.com) 
 Ioke creator (http://ioke.org)
 JRuby Core Developer (http://jruby.org)
 Developer, ThoughtWorks Studios (http://studios.thoughtworks.com)
 Practical JRuby on Rails (http://apress.com/book/view/9781590598818)

 "Yields falsehood when quined" yields falsehood when quined.

On Thu, Feb 12, 2009 at 10:39 AM, Gregory Brown
<gregory.t.brown@gmail.com> wrote:
> On Thu, Feb 12, 2009 at 12:36 PM, Rick DeNatale <rick.denatale@gmail.com> wrote:
>> On Thu, Feb 12, 2009 at 12:22 PM, Ezra Zygmuntowicz <ezmobius@gmail.com>wrote:
>>
>>>
>>>         Engine Yard is willing to step up as the official maintainer of
>>> ruby1.8.6. We can provide the right amount of human resources as well as
>>> server and QA resources with automated CI running the rubyspecs.
>
>> Although, I'm at a loss as to what you'd use for the version number on the
>> first maintenance release.
>
> Just a thought...
>
> RUBY_VERSION #=> "1.8.6"
> EY_RUBY_VERSION #=> "1.0.0"
>

which probably means Ruby 1.8.6.1 or Ruby186 1.0


> -greg
>
>



-- 
thanks,
-pate
-------------------------
   Duty makes us do things, Love make us do things well.
http://on-ruby.blogspot.com
http://eldersjournal.blogspot.com

Ezra Zygmuntowicz wrote:
>
>      Engine Yard is willing to step up as the official maintainer of 
> ruby1.8.6. We can provide the right amount of human resources as well 
> as server and QA resources with automated CI running the rubyspecs.

+1

Personally, I'd rather see a 1.9-compatible Merb, but it's looking like 
I'll have to wait for Rails 3 for that.

On Feb 12, 2009, at 3:03 AM, Brian Candler wrote:

> As for numbering, it's not so important, but the current scheme is  
> silly
> and appears to be based on an irrational fear of exceeding 1.9.  
> AFAICT,
> this is either because the string "1.10" doesn't sort after "1.9", or
> because 2.0 would somehow imply the language is especially "blessed"  
> or
> "finalised".

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.

Also, it was decided that it's silly to lose an entire branch for  
development (like 1.7).  Thus x.x.0 now means development and we only  
lose one version number.  That's why 1.9.1 is the first stable release  
of the 1.9 branch.

I feel like that all makes sense.

James Edward Gray II

Hi --

On Fri, 13 Feb 2009, James Coglan wrote:

>>
>>
>>
>> What do you mean with "Hash ordering"?
>> An order for Hash instances? Hash doesn't define a <=> method.
>> Or iteration order of Hash elements? That wasn't defined
>> in 1.8.6 (I don't know if it is in 1.8.7).
>
>
>
> In 1.8.6, iteration order would be the same as the order that the keys
> appear in the source. 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).

Hashes aren't ordered at all in 1.8, as far as I know. This works the
same in 1.8.6 and 1.8.7:

irb(main):002:0> h = {3,4,1,2}
=> {1=>2, 3=>4}
irb(main):003:0> h.each {|*x| p x }
[[1, 2]]
[[3, 4]]
=> {1=>2, 3=>4}

and here's a 1.8.7 case with individual key insertion:

irb(main):001:0> h = {}
=> {}
irb(main):002:0> h[3] = 4
=> 4
irb(main):003:0> h[1] = 2
=> 2
irb(main):004:0> h.each {|*x| p x }
[[1, 2]]
[[3, 4]]


David

-- 
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2)

http://www.wishsight.com => Independent, social wishlist management!

2009/2/12 James Coglan <jcoglan@googlemail.com>:
>>
>>
>>
>> What do you mean with "Hash ordering"?
>> An order for Hash instances? Hash doesn't define a <=> method.
>> Or iteration order of Hash elements? That wasn't defined
>> in 1.8.6 (I don't know if it is in 1.8.7).
>
>
>
> In 1.8.6, iteration order would be the same as the order that the keys
> appear in the source.

Iteration order is undefined, even for hash literals.
This is on *my* machine:

    $ ruby -v -e '{2 => 0, 1 => 0}.each_pair { |k,v| p k }'
    ruby 1.8.6 (2007-09-24 patchlevel 111) [x86_64-linux]
    1
    2

Your code happened to work by chance.

> 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.

Stefan

On Thu, Feb 12, 2009 at 9:22 AM, Ezra Zygmuntowicz <ezmobius@gmail.com> wrote:
>
>         Engine Yard is willing to step up as the official maintainer of
> ruby1.8.6. We can provide the right amount of human resources as well as
> server and QA resources with automated CI running the rubyspecs.
>
>        I feel that it is very important to keep a stable ruby 1.8.6 lineage
> for some time to come.
>
>        Matz has stated that he is willing to pass the torch on maintenance
> of ruby1.8.6 and we would like to step up to the plate for the whole ruby
> community. Please respond here if you think Engine yard would make good
> maintainers of the ruby1.8.6 lineage

Thanks!! Yes, I think you'd be ideal for this. I do have some questions, though:

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

2. Will this impact Rubinius?

3. Will there be a contribution to the Windows One-Click Installer
project as part of this?

4. Will there be some "community management" / "marketing" effort
associated with interfacing to the major Linux distros?
(Debian/Ubuntu, Fedora/Red Hat/CentOS, openSUSE/SLES/Novell for sure,
and probably Gentoo as well)


-- 
M. Edward (Ed) Borasky

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

On Thu, Feb 12, 2009 at 12:55 PM, pat eyler <pat.eyler@gmail.com> wrote:
> On Thu, Feb 12, 2009 at 10:39 AM, Gregory Brown
> <gregory.t.brown@gmail.com> wrote:
>> On Thu, Feb 12, 2009 at 12:36 PM, Rick DeNatale <rick.denatale@gmail.com> wrote:
>>> On Thu, Feb 12, 2009 at 12:22 PM, Ezra Zygmuntowicz <ezmobius@gmail.com>wrote:
>>>
>>>>
>>>>         Engine Yard is willing to step up as the official maintainer of
>>>> ruby1.8.6. We can provide the right amount of human resources as well as
>>>> server and QA resources with automated CI running the rubyspecs.
>>
>>> Although, I'm at a loss as to what you'd use for the version number on the
>>> first maintenance release.
>>
>> Just a thought...
>>
>> RUBY_VERSION #=> "1.8.6"
>> EY_RUBY_VERSION #=> "1.0.0"
>>
>
> which probably means Ruby 1.8.6.1 or Ruby186 1.0

Yeah, I think maybe 1.8.6.1 is a better idea than what I offered, actually.

-greg

-- 
Technical Blaag at: http://blog.majesticseacreature.com
 Non-tech stuff at: http://metametta.blogspot.com
"Ruby Best Practices"  Book now in O'Reilly Roughcuts:
http://rubybestpractices.com

I really feel that Ruby1.8.6 "deserves" more respect. It will probably
be in use for a long time yet.
Now I will not say to whomever is doing this great job on Ruby1.8 you
have to do this or that, I am not *that* stupid.
But those of us, who simply express their sincere opinion on the
subject should not be treated as a mob, or somebody too stupid to
follow to 1.9.1 neither, hopefully most of us agree with this?

Cheers
Robert



-- 
It is change, continuing change, inevitable change, that is the
dominant factor in society today. No sensible decision can be made any
longer without taking into account not only the world as it is, but
the world as it will be ... ~ Isaac Asimov

+1, because things have broken.

I am happy with 1.8.6 and 1.9. It's just that 1.8.7 introduces a lot
of noise, anyone would expect it to be compatible with 1.8.6, as
mentioned.

Justin Collins wrote:
> Joel VanderWerf wrote:
>> Bill Kelly wrote:
>>>
>>> From: "Rick DeNatale" <rick.denatale@gmail.com>
>>>>
>>>> As I remember it, Matz didn't want to have a version number like 1.8.10
>>>
>>> For what it's worth, my recollection is that matz wasn't
>>> _conceptually_ opposed to it, but rather it was not considered
>>> acceptable to break the existing code in the field which performed
>>> version checks based on string compares:
>>>
>>>>> "1.8.9" > "1.8.8"
>>> => true
>>>
>>>>> "1.8.10" > "1.8.9"
>>> => false
>>
>> I remember that... did anyone ever suggest other number bases?
>>
>> irb(main):001:0> "1.8.9" > "1.8.8"
>> => true
>> irb(main):002:0> "1.8.A" > "1.8.8"
>> => true
>>
>> Nah, too weird!
>>
> 
> I was looking at Erlang the other day.
> On the front page of erlang.org:
> 
> "Erlang/OTP R12B-5 released*"*

Someday, they'll get up to 27B-6.... (sorry, way too off-topic now).

-- 
       vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407

2009/2/12 Ezra Zygmuntowicz <ezmobius@gmail.com>:
> Please respond here if you think Engine yard would make good
> maintainers of the ruby1.8.6 lineage

That'd be great!

Rupert

[Note:  parts of this message were removed to make it a legal post.]

On Thu, Feb 12, 2009 at 12:54 PM, Ola Bini <ola.bini@gmail.com> wrote:

> Rick DeNatale wrote:
>
>> On Thu, Feb 12, 2009 at 12:22 PM, Ezra Zygmuntowicz <ezmobius@gmail.com
>> >wrote:
>>
>>
>>
>>>        Engine Yard is willing to step up as the official maintainer of
>>> ruby1.8.6. We can provide the right amount of human resources as well as
>>> server and QA resources with automated CI running the rubyspecs.
>>>
>>>       I feel that it is very important to keep a stable ruby 1.8.6
>>> lineage
>>> for some time to come.
>>>
>>>       Matz has stated that he is willing to pass the torch on maintenance
>>> of ruby1.8.6 and we would like to step up to the plate for the whole ruby
>>> community. Please respond here if you think Engine yard would make good
>>> maintainers of the ruby1.8.6 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?
>

As long as the downstream packagers pick up on it, but without additional
help, I think that most systems would treat 1.8.7 as compatible with, and
'better' than 1.8.6.x.

Examples.

Debian only uses the major and minor to differentiate different packages.
The Ubuntu list of Ruby packages illustrates this:
http://packages.ubuntu.com/search?keywords=ruby  There are separate Ruby1.8
and Ruby1.9 packages.

Note that the newer Debian systems map Ruby1.8 to Ruby 1.8.7  they also seem
to use patchlevel and other information to generate their own fourth level
version numbers

Macports only seems to have s single Ruby which is currently at 1.8.7
 >port list ruby
ruby                           @1.8.7-p72      lang/ruby

Considering how much trouble there's been reconciling the issues around
rubygems and debian, I'm not very confident that package maintainers will
treat 1.8.6.x and 1.8.7 as different upstream versions.

But I 'll reiterate that I think that the idea of maintaining 1.8.6 with
fixed semantics is a good idea.

-- 
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale

On Thu, Feb 12, 2009 at 11:35 AM, Rick DeNatale <rick.denatale@gmail.com> wrote:
> As long as the downstream packagers pick up on it, but without additional
> help, I think that most systems would treat 1.8.7 as compatible with, and
> 'better' than 1.8.6.x.
>
[elided]
>
> But I 'll reiterate that I think that the idea of maintaining 1.8.6 with
> fixed semantics is a good idea.

Good points.  I wonder what matz is willing to turn over.  If it's the 1.8 line,
then the next release should probably be 1.8.8 and represent a
continuation of the 1.8.6 line.  If he wants to maintain a 1.8.X and 1.9.X
line, then I think we need to think about either a 1.8.6.X or a RubyClassic
1.0 (or something like it)



>
> --
> Rick DeNatale
>
> Blog: http://talklikeaduck.denhaven2.com/
> Twitter: http://twitter.com/RickDeNatale
>



-- 
thanks,
-pate
-------------------------
   Duty makes us do things, Love make us do things well.
http://on-ruby.blogspot.com
http://eldersjournal.blogspot.com

Hi,

At Fri, 13 Feb 2009 02:36:06 +0900,
Rick DeNatale wrote in [ruby-talk:327919]:
> Although, I'm at a loss as to what you'd use for the version number on the
> first maintenance release.

1.8.6-p###.

-- 
Nobu Nakada

2009/2/12 Gregory Brown <gregory.t.brown@gmail.com>:
> On Thu, Feb 12, 2009 at 12:22 PM, Ezra Zygmuntowicz <ezmobius@gmail.com> wrote:
>>         Engine Yard is willing to step up as the official maintainer of
>> ruby1.8.6.
>> (...)
>
> This would give those of us who need a stable legacy 1.8 to follow a
> place to look for bug fixes and stablizations.

Gregory, there is no Ruby 1.8 and has never been. There have been
1.8.0, 1.8.1, up to 1.8.7, each one differing from the others. I'm
sure that for each new version you can find new methods introduced
and/or behaviour of existing methods changed. This was the point I
never understood: what's so special about the transition to 1.8.7?

I think what most of you really want is to keep 1.8.6, not some
ominous "Ruby 1.8", what ever this should be. Ezra has put this right:
"maintainer of 1.8.6".

So, you keep your 1.8.6, and others can go on to 1.8.7 and beyond. I
think this would be a perfect solution.

Regards,
Pit

On Thu, Feb 12, 2009 at 1:59 PM, Pit Capitain <pit.capitain@gmail.com> wrote:
> 2009/2/12 Gregory Brown <gregory.t.brown@gmail.com>:
>> On Thu, Feb 12, 2009 at 12:22 PM, Ezra Zygmuntowicz <ezmobius@gmail.com> wrote:
>>>         Engine Yard is willing to step up as the official maintainer of
>>> ruby1.8.6.
>>> (...)
>>
>> This would give those of us who need a stable legacy 1.8 to follow a
>> place to look for bug fixes and stablizations.
>
> Gregory, there is no Ruby 1.8 and has never been. There have been
> 1.8.0, 1.8.1, up to 1.8.7, each one differing from the others. I'm
> sure that for each new version you can find new methods introduced
> and/or behaviour of existing methods changed. This was the point I
> never understood: what's so special about the transition to 1.8.7?

You keep saying this but frankly, it's ridiculous.  Yes, you can find
changes.  In Ruby 1.8.7, you get clubbed over the head with them.

> I think what most of you really want is to keep 1.8.6, not some
> ominous "Ruby 1.8", what ever this should be. Ezra has put this right:
> "maintainer of 1.8.6".
>
> So, you keep your 1.8.6, and others can go on to 1.8.7 and beyond. I
> think this would be a perfect solution.

We're not in disagreement here.  It's just been my experience that I
can write code on 1.8.6 without thinking about back-wards
compatibility with earlier versions, for the most part.  We all know
that things have changed, but not in so radical a fashion.

What I was supporting was a stable 'flavor' of Ruby 1.8, in the form
of a EY supported 1.8.6.

And I agree completely that this solves the issue without forcing
people in one direction or the other.  If ruby-core wishes to support
1.8.7 and beyond, those who like the idea will not be left
disappointed.

-greg

-- 
Technical Blaag at: http://blog.majesticseacreature.com
 Non-tech stuff at: http://metametta.blogspot.com
"Ruby Best Practices"  Book now in O'Reilly Roughcuts:
http://rubybestpractices.com

2009/2/12 Gregory Brown <gregory.t.brown@gmail.com>:
> On Thu, Feb 12, 2009 at 1:59 PM, Pit Capitain <pit.capitain@gmail.com> wrote:
>> Gregory, there is no Ruby 1.8 and has never been. There have been
>> 1.8.0, 1.8.1, up to 1.8.7, each one differing from the others.
>
> You keep saying this but frankly, it's ridiculous.  Yes, you can find
> changes.  In Ruby 1.8.7, you get clubbed over the head with them.

So we agree to disagree. Though I'd be interested in what you'd define
as "Ruby 1.8". Is it 1.8.6? Why not 1.8.2? Does 1.8.5 qualify as being
a "Ruby 1.8", despite the differences to 1.8.6? In the end I'm sure it
will be 1.8.6, so why not name it as such? Why interpret more into it
as it really is?

> We're not in disagreement here.  It's just been my experience that I
> can write code on 1.8.6 without thinking about back-wards
> compatibility with earlier versions, for the most part.  We all know
> that things have changed, but not in so radical a fashion.

Hmm, let's see how radical a change 1.8.7 has been until now:
Hash#hash has been changed (or should I say: fixed), it's not allowed
to allocate new objects during garbage collection anymore (the SWIG
problem), plus (admittedly a large number of) new features have been
added. I wouldn't call this radical, but, again, we just disagree
here, so I'll shut up now.

Regards,
Pit

On Feb 12, 2009, at 1:47 PM, Nobuyoshi Nakada wrote:

> Hi,
>
> At Fri, 13 Feb 2009 02:36:06 +0900,
> Rick DeNatale wrote in [ruby-talk:327919]:
>> Although, I'm at a loss as to what you'd use for the version number  
>> on the
>> first maintenance release.
>
> 1.8.6-p###.

+1 on that.  I never even consider downloading 1.8.7 or later for a  
customer... I just grab the most recent 1.8.6-pxxx release.  If p288  
came out and didn't break anything, I'd start using that...

Yours,

tom

On Thu, Feb 12, 2009 at 2:33 PM, Pit Capitain <pit.capitain@gmail.com> wrote:
> 2009/2/12 Gregory Brown <gregory.t.brown@gmail.com>:
>> On Thu, Feb 12, 2009 at 1:59 PM, Pit Capitain <pit.capitain@gmail.com> wrote:
>>> Gregory, there is no Ruby 1.8 and has never been. There have been
>>> 1.8.0, 1.8.1, up to 1.8.7, each one differing from the others.
>>
>> You keep saying this but frankly, it's ridiculous.  Yes, you can find
>> changes.  In Ruby 1.8.7, you get clubbed over the head with them.
>
> So we agree to disagree. Though I'd be interested in what you'd define
> as "Ruby 1.8". Is it 1.8.6? Why not 1.8.2? Does 1.8.5 qualify as being
> a "Ruby 1.8", despite the differences to 1.8.6? In the end I'm sure it
> will be 1.8.6, so why not name it as such? Why interpret more into it
> as it really is?

I understand what you mean here, and actually, you're right in saying
that the term "Ruby 1.8" is completely amorphous.

But I suppose what I'm saying is that from 1.8.2 up until 1.8.6, I did
not once say "Wow! now I can do all this new cool stuff!".   I also
didn't worry too much about whether code I wrote on my latest Ruby 1.8
version would work in various out of date production environments.  I
did not worry about patches from contributors having the same problem
in my open source projects.

The situation also might be different for me if 1.9 didn't exist.  But
I'm not sure you'll agree with my reasoning on that, and it's not
terribly important anyway, so I won't elaborate further.

>> We're not in disagreement here.  It's just been my experience that I
>> can write code on 1.8.6 without thinking about back-wards
>> compatibility with earlier versions, for the most part.  We all know
>> that things have changed, but not in so radical a fashion.
>
> Hmm, let's see how radical a change 1.8.7 has been until now:
> Hash#hash has been changed (or should I say: fixed), it's not allowed
> to allocate new objects during garbage collection anymore (the SWIG
> problem), plus (admittedly a large number of) new features have been
> added. I wouldn't call this radical, but, again, we just disagree
> here, so I'll shut up now.

I think you're looking at this from the perspective of standalone Ruby
code, and I can see a bit of what you're saying from that perspective.
 But I'm speaking based on my experience of having to deploy code to
older versions of Ruby in a commercial setting, as well as running
several mainstream open source projects that have an active
contributor base.   It is possible that we're 'both right' in our own
situations, and that this solution of having EY run 1.8.6 might give
us the best of both worlds.

I apologize for using vague terminology about '1.8', it's probably the
main source of dispute here.

-greg

Stefan Lang wrote:

>>> Important is backwards compatibility and Ruby 1.8.7
>>> is backwards compatible. Nobody so far has shown
>>> where 1.8.7 is not backwards compatible.
>> require 'rubynode'
> 
> From http://rubynode.rubyforge.org/:
>   "RubyNode is a library that allows read only access to Ruby's
>   internal NODE structure."
> 
> It's cool that such libraries exist, but AFAIK MRI's
> internal AST is  not part of its public API, much
> less part of Ruby 1.8, the language.

So if Ruby 1.8.7 had broken RubyInline, that would be okay?

Pit Capitain wrote:
> 2009/2/12 Gregory Brown <gregory.t.brown@gmail.com>:
>> On Thu, Feb 12, 2009 at 1:59 PM, Pit Capitain <pit.capitain@gmail.com> wrote:
>>> Gregory, there is no Ruby 1.8 and has never been. There have been
>>> 1.8.0, 1.8.1, up to 1.8.7, each one differing from the others.
>> You keep saying this but frankly, it's ridiculous.  Yes, you can find
>> changes.  In Ruby 1.8.7, you get clubbed over the head with them.
> 
> So we agree to disagree. Though I'd be interested in what you'd define
> as "Ruby 1.8". Is it 1.8.6? Why not 1.8.2? Does 1.8.5 qualify as being
> a "Ruby 1.8", despite the differences to 1.8.6? In the end I'm sure it
> will be 1.8.6, so why not name it as such? Why interpret more into it
> as it really is?

"Ruby 1.8" is that which installs libraries into
$PREFIX_DIR/lib/ruby/1.8 .

-- 
       vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407

2009/2/12 Phlip <phlip2005@gmail.com>:
> Stefan Lang wrote:
>
>>>> Important is backwards compatibility and Ruby 1.8.7
>>>> is backwards compatible. Nobody so far has shown
>>>> where 1.8.7 is not backwards compatible.
>>>
>>> require 'rubynode'
>>
>> From http://rubynode.rubyforge.org/:
>>  "RubyNode is a library that allows read only access to Ruby's
>>  internal NODE structure."
>>
>> It's cool that such libraries exist, but AFAIK MRI's
>> internal AST is  not part of its public API, much
>> less part of Ruby 1.8, the language.
>
> So if Ruby 1.8.7 had broken RubyInline, that would be okay?

If it relies on MRI internals there would definitely be
no fault on the 1.8 maintainers side.

This is common sense. If you rely on internals and monkey
patching, your code can break when you update a dependency.

Stefan

On Thu, Feb 12, 2009 at 11:07 AM, Gregory Brown
<gregory.t.brown@gmail.com> wrote:
> We're not in disagreement here.  It's just been my experience that I
> can write code on 1.8.6 without thinking about backwards
> compatibility with earlier versions, for the most part.  We all know
> that things have changed, but not in so radical a fashion.
>
> What I was supporting was a stable 'flavor' of Ruby 1.8, in the form
> of a EY supported 1.8.6.
>
> And I agree completely that this solves the issue without forcing
> people in one direction or the other.  If ruby-core wishes to support
> 1.8.7 and beyond, those who like the idea will not be left
> disappointed.

But that still leaves a communication gap between two groups of
implementers -- Engine Yard and "Ruby-Core" -- and the Linux distros
that are probably only going to package *one* Ruby and are expecting
*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
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.
>
> -greg
>
> --
> Technical Blaag at: http://blog.majesticseacreature.com
>  Non-tech stuff at: http://metametta.blogspot.com
> "Ruby Best Practices"  Book now in O'Reilly Roughcuts:
> http://rubybestpractices.com
>
>



-- 
M. Edward (Ed) Borasky

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

2009/2/12 Gregory Brown <gregory.t.brown@gmail.com>:
> But I suppose what I'm saying is that from 1.8.2 up until 1.8.6, I did
> not once say "Wow! now I can do all this new cool stuff!".   I also
> didn't worry too much about whether code I wrote on my latest Ruby 1.8
> version would work in various out of date production environments.  I
> did not worry about patches from contributors having the same problem
> in my open source projects.

Yeah, I think I understand you, too. Of course you could develop right
away in 1.8.7 without using the new features. This code should still
work with 1.8.6. But it would require you to always think about this
necessity, and you would have no immediate feedback when you
accidentally used one of the new features.

> I apologize for using vague terminology about '1.8', it's probably the
> main source of dispute here.

There's absolutely no reason to apologize, Greg. To me the main source
of dispute was that so many people were telling "1.8.7 breaks
compatibility with 1.8.6" but almost no none could prove this.

Just one more remark to Joel's post, and then I'll definitely shut up.

2009/2/12 Joel VanderWerf <vjoel@path.berkeley.edu>:
> "Ruby 1.8" is that which installs libraries into
> $PREFIX_DIR/lib/ruby/1.8 .

Hmm, currently this includes every release from 1.8.0 to 1.8.7, right?

Regards,
Pit

On Feb 12, 4:13=A0pm, "M. Edward (Ed) Borasky" <zzn...@gmail.com> wrote:
> On Thu, Feb 12, 2009 at 9:22 AM, Ezra Zygmuntowicz <ezmob...@gmail.com> w=
rote:
>
> > =A0 =A0 =A0 =A0 Engine Yard is willing to step up as the official maint=
ainer of
> > ruby1.8.6. We can provide the right amount of human resources as well a=
s
> > server and QA resources with automated CI running the rubyspecs.
>
> > =A0 =A0 =A0 =A0I feel that it is very important to keep a stable ruby 1=
..8.6 lineage
> > for some time to come.
>
> > =A0 =A0 =A0 =A0Matz has stated that he is willing to pass the torch on =
maintenance
> > of ruby1.8.6 and we would like to step up to the plate for the whole ru=
by
> > community. Please respond here if you think Engine yard would make good
> > maintainers of the ruby1.8.6 lineage
>

I'll like to jump late on this thread, but just not trying to add more
noise...

> Thanks!! Yes, I think you'd be ideal for this. I do have some questions, =
though:
>
> 1. Would there be a chance of merging the efficiencies of Ruby
> Enterprise Edition, especially copy-on-write friendliness, into the
> "Engine Yard 1.8.6 stack?"
>

CoW will not be cross-platform compatible (at least not for Windows).
The amount of changes needed by CoW are so big because the C code of
Ruby sometimes can be complicated.

> 2. Will this impact Rubinius?

I hope not, and I think it wouldn't.

> 3. Will there be a contribution to the Windows One-Click Installer
> project as part of this?

I wish they do, or at least merge contributions back :-)

Regards,
--
Luis Lavena

On Thu, Feb 12, 2009 at 10:19 PM, Pit Capitain <pit.capitain@gmail.com> wrote:

> There's absolutely no reason to apologize, Greg. To me the main source
> of dispute was that so many people were telling "1.8.7 breaks
> compatibility with 1.8.6" but almost no none could prove this.
That is a very good point. My issues however are much more of a
practical or psychological reason
The pure fact that incompatibilities exist, however small, will
certainly not assure me about BW (8.7 -> 8.6 )compatibility for future
releases and neither for FW(8.6->8.7+).
That's why I voted on this thread and not the other one.

I felt that Greg somehow was very much anticipating trouble rather
than seeing it around already. I was quite impressed by that vision,
but that of course does not mean that he/we is/are correct :).

Cheers
Robert

Yossef Mendelssohn wrote:
> Or maybe you meant the bug was that people were comparing strings at
> all, which is understandable (though a strange word choice).

Yes, that's what I meant.

- Charlie

[Note:  parts of this message were removed to make it a legal post.]

2009/2/12 David A. Black <dblack@rubypal.com>

> Hi --
>
> On Fri, 13 Feb 2009, James Coglan wrote:
>
>
>>>
>>>
>>> What do you mean with "Hash ordering"?
>>> An order for Hash instances? Hash doesn't define a <=> method.
>>> Or iteration order of Hash elements? That wasn't defined
>>> in 1.8.6 (I don't know if it is in 1.8.7).
>>>
>>
>>
>>
>> In 1.8.6, iteration order would be the same as the order that the keys
>> appear in the source. 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).
>>
>
> Hashes aren't ordered at all in 1.8, as far as I know.



I realise that there is no explicit iteration order specified for hashes in
1.8. All I know is that this patch fixed by 1.8.7 bugs:

http://github.com/jcoglan/packr/commit/9ece59428bbd1bfd497b45a2ae4de2d163a24849

Basically involves inserting keys in an explicit order rather than using
hash literals. This project uses a bunch of custom collection classes but
they're basically wrappers for arrays and hashes that merge array and hash
functionality into a single class. The constructors would iterate over the
hashes provided and insert values, and this insertion order changed in
1.8.7.

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. I still have a regex-related bug in
this project that I've been unable to fix under 1.8.7. In fact, if anyone is
able to fix the last remaining test failure I'd be incredibly grateful.

Hi --

On Fri, 13 Feb 2009, James Coglan wrote:

> 2009/2/12 David A. Black <dblack@rubypal.com>
>
>> Hi --
>>
>> On Fri, 13 Feb 2009, James Coglan wrote:
>>
>>
>>>>
>>>>
>>>> What do you mean with "Hash ordering"?
>>>> An order for Hash instances? Hash doesn't define a <=> method.
>>>> Or iteration order of Hash elements? That wasn't defined
>>>> in 1.8.6 (I don't know if it is in 1.8.7).
>>>>
>>>
>>>
>>>
>>> In 1.8.6, iteration order would be the same as the order that the keys
>>> appear in the source. 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).
>>>
>>
>> Hashes aren't ordered at all in 1.8, as far as I know.
>
>
>
> I realise that there is no explicit iteration order specified for hashes in
> 1.8. All I know is that this patch fixed by 1.8.7 bugs:

Sorry, I misunderstood what you were getting at.

> http://github.com/jcoglan/packr/commit/9ece59428bbd1bfd497b45a2ae4de2d163a24849
>
> Basically involves inserting keys in an explicit order rather than using
> hash literals. This project uses a bunch of custom collection classes but
> they're basically wrappers for arrays and hashes that merge array and hash
> functionality into a single class. The constructors would iterate over the
> hashes provided and insert values, and this insertion order changed in
> 1.8.7.
>
> 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. I still have a regex-related bug in
> this project that I've been unable to fix under 1.8.7. In fact, if anyone is
> able to fix the last remaining test failure I'd be incredibly grateful.

I can't get any of your tests to fail under 1.8.7, at least the one
I've got installed on the machine where I tried it (pl0).


David

-- 
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2)

http://www.wishsight.com => Independent, social wishlist management!

On 2009-02-12, Ezra Zygmuntowicz <ezmobius@gmail.com> wrote:
>
> 	 Engine Yard is willing to  step up as the official maintainer
> of ruby1.8.6. We can provide  the right amount of human resources as
> well  as server  and  QA  resources with  automated  CI running  the
> rubyspecs.

This is excellent!

Jeremy Henty

The entire 1.8.x series should be backward compatible to 1.8.6 NOT 
forward compatible to 1.9.x.
-- 
Posted via http://www.ruby-forum.com/.

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+
> 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.
> 
> -greg

It is absolutely wrong to change major API and syntax within a major 
release series.

1.8.8 should definitely go back to 100% syntactical and regression test 
compatability with 1.8.6

Wayne
-- 
Posted via http://www.ruby-forum.com/.

Stefan Lang wrote:

> 2009/2/11 James Gray <james@grayproductions.net>:
> > On Feb 11, 2009, at 3:42 PM, Pit Capitain wrote:
> > 
> >> 2009/2/11 Rick DeNatale <rick.denatale@gmail.com>:
> > > > 
> >>> Ruby 1.8.7 is NOT compatible with Ruby 1.8.6.
> > > 
> >> I've seen many people claiming this, and they might be right of
> >> course, but no one has shown any examples yet.
> > 
> > This is trivial to prove.  This code:
> > 
> >  Object.new.tap { |o| p o }
> > 
> > runs on 1.8.7 and not 1.8.6.
> 
> 1.8.x releases always introduced new methods.
> If Ruby releases were done how the mob here wants
> them, we wouldn't have a single new method since
> 1.8.0 was released in 2003.
> 
> Important is backwards compatibility and Ruby 1.8.7
> is backwards compatible. Nobody so far has shown
> where 1.8.7 is not backwards compatible.
> 
> That Rails broke was their own fault. They extend core
> classes, so clashes are to be expected. If they had
> tested with an 1.8.7 release candidate, I'm sure they
> could have worked out a solution with the 1.8 maintainers.
> 
> Stefan

+1

Stefan Lang wrote:

> 2009/2/12 James Coglan <jcoglan@googlemail.com>:
> > > 
> > > 
> > > 
> >> What do you mean with "Hash ordering"?
> >> An order for Hash instances? Hash doesn't define a <=> method.
> >> Or iteration order of Hash elements? That wasn't defined
> >> in 1.8.6 (I don't know if it is in 1.8.7).
> > 
> > 
> > 
> > In 1.8.6, iteration order would be the same as the order that the
> > keys appear in the source.
> 
> Iteration order is undefined, even for hash literals.
> This is on my machine:
> 
>     $ ruby -v -e '{2 => 0, 1 => 0}.each_pair { |k,v| p k }'
>     ruby 1.8.6 (2007-09-24 patchlevel 111) [x86_64-linux]
>     1
>     2
> 
> Your code happened to work by chance.
> 
> > 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.
> 
> Stefan

+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.

An element is fetched a hash-table by key, not by position,
which is undefined.

Hi,

At Fri, 13 Feb 2009 09:16:39 +0900,
James Coglan wrote in [ruby-talk:327995]:
> I realise that there is no explicit iteration order specified for hashes in
> 1.8. All I know is that this patch fixed by 1.8.7 bugs:
> 
> http://github.com/jcoglan/packr/commit/9ece59428bbd1bfd497b45a2ae4de2d163a24849
> 
> Basically involves inserting keys in an explicit order rather than using
> hash literals. This project uses a bunch of custom collection classes but
> they're basically wrappers for arrays and hashes that merge array and hash
> functionality into a single class. The constructors would iterate over the
> hashes provided and insert values, and this insertion order changed in
> 1.8.7.

Hash in 1.8 doesn't define any kind of "order".  It's
definitely a bug in your code as you use the word "order".

> 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. I still have a regex-related bug in
> this project that I've been unable to fix under 1.8.7. In fact, if anyone is
> able to fix the last remaining test failure I'd be incredibly grateful.

Could you post it in another thread?

-- 
Nobu Nakada

pat eyler wrote:

> At work, we've already been bitten by 1.8.6 -> 1.8.7 problems.
> I can't tell you how much I don't want to see 1.8.8 move even
> further away from 1.8.6.
> 
> Please, leave the 1.8 line as compatible as possible, leave
> the API breakage to the 1.8 -> 1.9 migration.
> 
> On Wed, Feb 11, 2009 at 12:00 PM, Zachary Brown <zac@zacbrown.org>
> wrote:
> > As a new Ruby user coming to the language, I've found it fairly
> > 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?

David A. Black wrote:

> On Fri, 13 Feb 2009, David A. Black wrote:
> 
> > Much, much more has been said about the issues involved in the
> > recent version policy than that it's bad to introduce any new
> > methods in teeny versions (and that, as far as I can see, has not
> > been said).
> 
> A followup to this:
> 
> I think there are two important points to keep in mind. First, it's a
> matter of degree, not kind. In other words, no one is saying that
> 1.8.7 should be indistinguishable from 1.8.6. It's more the quantity
> of change that's at issue. Here's a very crude metric, showing the
> results of instance_methods(false) for various classes and modules
> across three 1.8 versions:
> 
> 1.8.2
> String: 83
> Array: 71
> Hash: 45
> Range: 15
> Enumerable: 22
> 
> 1.8.6
> String: 83
> Array: 71
> Hash: 45
> Range: 15
> Enumerable: 22
> 
> 1.8.7
> String: 91
> Array: 83
> Hash: 47
> Range: 15
> Enumerable: 43
> 
> (Gotta love Range :-)

No, I don't.  I enjoy having new methods, so long as the behavior of
the old methods is "exempt from mutation".

On 12/02/2009, M. Edward (Ed) Borasky <zznmeb@gmail.com> wrote:
> On Thu, Feb 12, 2009 at 11:07 AM, Gregory Brown
>  <gregory.t.brown@gmail.com> wrote:
>  > We're not in disagreement here.  It's just been my experience that I
>
> > can write code on 1.8.6 without thinking about backwards
>
> > compatibility with earlier versions, for the most part.  We all know
>  > that things have changed, but not in so radical a fashion.
>  >
>
> > What I was supporting was a stable 'flavor' of Ruby 1.8, in the form
>  > of a EY supported 1.8.6.
>  >
>  > And I agree completely that this solves the issue without forcing
>  > people in one direction or the other.  If ruby-core wishes to support
>  > 1.8.7 and beyond, those who like the idea will not be left
>  > disappointed.
>
>  But that still leaves a communication gap between two groups of
>  implementers -- Engine Yard and "Ruby-Core" -- and the Linux distros
>  that are probably only going to package *one* Ruby and are expecting
>  *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

[Note:  parts of this message were removed to make it a legal post.]

>
> 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.

2009/2/13 James Coglan <jcoglan@googlemail.com>:
> 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).
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

[Note:  parts of this message were removed to make it a legal post.]

2009/2/13 William James <w_a_x_man@yahoo.com>

> Stefan Lang wrote:
>
> > Iteration order is undefined, even for hash literals.
> > This is on my machine:
> >
> >     $ ruby -v -e '{2 => 0, 1 => 0}.each_pair { |k,v| p k }'
> >     ruby 1.8.6 (2007-09-24 patchlevel 111) [x86_64-linux]
> >     1
> >     2
> >
> > Your code happened to work by chance.
> >
> > > 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.
> >
> > Stefan
>
> +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.

James Coglan 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.

[Note:  parts of this message were removed to make it a legal post.]

2009/2/13 William James <w_a_x_man@yahoo.com>

> James Coglan 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.


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 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!

Ezra Zygmuntowicz wrote:
>
>      Engine Yard is willing to step up as the official maintainer of 
> ruby1.8.6. We can provide the right amount of human resources as well 
> as server and QA resources with automated CI running the rubyspecs.
>
>     I feel that it is very important to keep a stable ruby 1.8.6 
> lineage for some time to come.
>
>     Matz has stated that he is willing to pass the torch on 
> maintenance of ruby1.8.6 and we would like to step up to the plate for 
> 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!)

[Note:  parts of this message were removed to make it a legal post.]

On Fri, Feb 13, 2009 at 12:15 AM, Nobuyoshi Nakada <nobu@ruby-lang.org>wrote:

> Hi,
>
> At Fri, 13 Feb 2009 09:16:39 +0900,
> James Coglan wrote in [ruby-talk:327995]:
> > I realise that there is no explicit iteration order specified for hashes
> in
> > 1.8. All I know is that this patch fixed by 1.8.7 bugs:
> >
> >
> http://github.com/jcoglan/packr/commit/9ece59428bbd1bfd497b45a2ae4de2d163a24849
> >
> > Basically involves inserting keys in an explicit order rather than using
> > hash literals. This project uses a bunch of custom collection classes but
> > they're basically wrappers for arrays and hashes that merge array and
> hash
> > functionality into a single class. The constructors would iterate over
> the
> > hashes provided and insert values, and this insertion order changed in
> > 1.8.7.
>
> Hash in 1.8 doesn't define any kind of "order".  It's
> 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/
Twitter: http://twitter.com/RickDeNatale

James Gray 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?

<ducking>
-- 
M. Edward (Ed) Borasky

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

[Note:  parts of this message were removed to make it a legal post.]

On Fri, Feb 13, 2009 at 4:53 AM, William James <w_a_x_man@yahoo.com> wrote:

> James Coglan 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.


Let me try to calm the waters on this particular part of the conversation.

A couple of years ago, there was a long discussion here, when some, led by
Hal Fulton IIRC,  advocated defining the order for enumerating Ruby hashes.

At that time, I argued vehemently to your point that hash tables are
inherently unordered, and therefore it was inconceivable to order them.

I was wrong.

First, although Ruby Hash is implemented using a hash table, they aren't
hash tables, they are Ruby objects which for better or worse are named
simply Hash.  Perhaps if they had been named something like Dictionary, or
Map, a name which doesn't betray the implementation, this all would have
been less controversial.

Sometime after that discussion, Matz, who I know has much more than a basic
understanding of hash-tables, decided that, yes,
defining the iteration order of Ruby hashes to  be by insertion order, and
that this was easily done with minimal impact to performance/space
requirements by linking buckets in the internal hash table used to IMPLEMENT
Hash, and made this change in Ruby 1.9, which has been backported to Ruby
1.8.7.

And as for whether or not changing something which was previously undefined
to something which is defined introduces a backwards compatibility issue, I
think it's pretty clear that it does not.

-- 
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale

Ola Bini wrote:
> Rick DeNatale wrote:
>> On Thu, Feb 12, 2009 at 12:22 PM, Ezra Zygmuntowicz
>> <ezmobius@gmail.com>wrote:
>>
>>  
>>>         Engine Yard is willing to step up as the official maintainer of
>>> ruby1.8.6. We can provide the right amount of human resources as well as
>>> server and QA resources with automated CI running the rubyspecs.
>>>
>>>        I feel that it is very important to keep a stable ruby 1.8.6
>>> lineage
>>> for some time to come.
>>>
>>>        Matz has stated that he is willing to pass the torch on
>>> maintenance
>>> of ruby1.8.6 and we would like to step up to the plate for the whole
>>> ruby
>>> community. Please respond here if you think Engine yard would make good
>>> maintainers of the ruby1.8.6 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.

[Note:  parts of this message were removed to make it a legal post.]

On Fri, Feb 13, 2009 at 4:50 AM, James Coglan <jcoglan@googlemail.com>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/
Twitter: http://twitter.com/RickDeNatale

Hi --

On Sat, 14 Feb 2009, Rick DeNatale wrote:

> Sometime after that discussion, Matz, who I know has much more than a basic
> understanding of hash-tables, decided that, yes,
> defining the iteration order of Ruby hashes to  be by insertion order, and
> that this was easily done with minimal impact to performance/space
> requirements by linking buckets in the internal hash table used to IMPLEMENT
> Hash, and made this change in Ruby 1.9, which has been backported to Ruby
> 1.8.7.

Hashes aren't ordered in 1.8.7, though.


David

-- 
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2)

http://www.wishsight.com => Independent, social wishlist management!

[Note:  parts of this message were removed to make it a legal post.]

2009/2/13 David A. Black <dblack@rubypal.com>

> Hi --
>
> On Sat, 14 Feb 2009, Rick DeNatale wrote:
>
>  Sometime after that discussion, Matz, who I know has much more than a
>> basic
>> understanding of hash-tables, decided that, yes,
>> defining the iteration order of Ruby hashes to  be by insertion order, and
>> that this was easily done with minimal impact to performance/space
>> requirements by linking buckets in the internal hash table used to
>> IMPLEMENT
>> Hash, and made this change in Ruby 1.9, which has been backported to Ruby
>> 1.8.7.
>>
>
> Hashes aren't ordered in 1.8.7, though.


Seconded -- 1.8.7 is precisely where my code that was relying on insertion
order *does not work*. Actually let me be more specific. My code was relying
on keys being inserted in the order they appear in a hash literal, and on
subsequent iteration occuring in the same order. My own code was maintaining
key order explicitly using an array of keys (
http://github.com/jcoglan/packr/blob/3.1/lib/packr/collection.rb), but when
using a hash literal to initialize an instance, the keys are not inserted in
literal appearance order in 1.8.7.

So it may be that 1.8.7 does use insertion order for iteration, but does not
use literal appearance order when creating a new hash.

Hi --

On Sat, 14 Feb 2009, James Coglan wrote:

> 2009/2/13 David A. Black <dblack@rubypal.com>
>
>> Hi --
>>
>> On Sat, 14 Feb 2009, Rick DeNatale wrote:
>>
>>  Sometime after that discussion, Matz, who I know has much more than a
>>> basic
>>> understanding of hash-tables, decided that, yes,
>>> defining the iteration order of Ruby hashes to  be by insertion order, and
>>> that this was easily done with minimal impact to performance/space
>>> requirements by linking buckets in the internal hash table used to
>>> IMPLEMENT
>>> Hash, and made this change in Ruby 1.9, which has been backported to Ruby
>>> 1.8.7.
>>>
>>
>> Hashes aren't ordered in 1.8.7, though.
>
>
> Seconded -- 1.8.7 is precisely where my code that was relying on insertion
> order *does not work*. Actually let me be more specific. My code was relying
> on keys being inserted in the order they appear in a hash literal, and on
> subsequent iteration occuring in the same order.

That doesn't happen in any 1.8 version, though. (Sorry; I feel like
something's going right past me, and I'll stop after this iteration
:-)


David

-- 
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2)

http://www.wishsight.com => Independent, social wishlist management!

[Note:  parts of this message were removed to make it a legal post.]

>
>
>> Seconded -- 1.8.7 is precisely where my code that was relying on insertion
>> order *does not work*. Actually let me be more specific. My code was
>> relying
>> on keys being inserted in the order they appear in a hash literal, and on
>> subsequent iteration occuring in the same order.
>>
>
> That doesn't happen in any 1.8 version, though. (Sorry; I feel like
> something's going right past me, and I'll stop after this iteration
> :-)



Regardless of whether they're *supposed* to, the Rubies I've used before
1.8.7 actually do iterate in insertion order. Could be machine/OS specific,
a fluke, whatever. The point is that 1.8.7 definitely does not iterate in
the order that keys appear in a literal, at least on my machine. If this is
supposed to now be defined behaviour I'll investigate further and file a bug
if necessary.

In article <b913ba1b0902130743j17a62d1ck9e8150912bfc8002@mail.gmail.com>,
  James Coglan <jcoglan@googlemail.com> writes:

> Regardless of whether they're *supposed* to, the Rubies I've used before
> 1.8.7 actually do iterate in insertion order. Could be machine/OS specific,
> a fluke, whatever. The point is that 1.8.7 definitely does not iterate in
> the order that keys appear in a literal, at least on my machine. If this is
> supposed to now be defined behaviour I'll investigate further and file a bug
> if necessary.

Would you show us an example which the insertion order is
preserved on 1.8.6 and not preserved on 1.8.7?

I tested as follows.  The order is changed since 1.9.
1.8.7 is same as 1.8.6 and older.

% all-ruby -e 'h = {2=>"b", 1=>"a"}; p h'
ruby-1.4.6(2000-08-16)         {1=>"a", 2=>"b"}
ruby-1.6.0(2000-09-19)         {1=>"a", 2=>"b"}
ruby-1.6.1(2000-09-27)         {1=>"a", 2=>"b"}
ruby-1.6.2(2000-12-25)         {1=>"a", 2=>"b"}
ruby-1.6.3(2001-03-19)         {1=>"a", 2=>"b"}
ruby-1.6.4(2001-06-04)         {1=>"a", 2=>"b"}
ruby-1.6.5(2001-09-19)         {1=>"a", 2=>"b"}
ruby-1.6.6(2001-12-26)         {1=>"a", 2=>"b"}
ruby-1.6.7(2002-03-01)         {1=>"a", 2=>"b"}
ruby-1.6.8(2002-12-24)         {1=>"a", 2=>"b"}
ruby-1.8.0(2003-08-04)         {1=>"a", 2=>"b"}
ruby-1.8.1(2003-12-25)         {1=>"a", 2=>"b"}
ruby-1.8.2(2004-12-25)         {1=>"a", 2=>"b"}
ruby-1.8.3(2005-09-21)         {1=>"a", 2=>"b"}
ruby-1.8.4(2005-12-24)         {1=>"a", 2=>"b"}
ruby-1.8.5(2006-08-25)         {1=>"a", 2=>"b"}
ruby-1.8.5p52(2007-06-07)      {1=>"a", 2=>"b"}
ruby-1.8.5p113(2007-09-23)     {1=>"a", 2=>"b"}
ruby-1.8.5p115(2008-03-03)     {1=>"a", 2=>"b"}
ruby-1.8.5p231(2008-06-20)     {1=>"a", 2=>"b"}
ruby-1.8.5head(2008-06-20p231) {1=>"a", 2=>"b"}
ruby-1.8.6p0(2007-03-13)       {1=>"a", 2=>"b"}
ruby-1.8.6p36(2007-06-07)      {1=>"a", 2=>"b"}
ruby-1.8.6p110(2007-09-23)     {1=>"a", 2=>"b"}
ruby-1.8.6p111(2007-09-24)     {1=>"a", 2=>"b"}
ruby-1.8.6p114(2008-03-03)     {1=>"a", 2=>"b"}
ruby-1.8.6p230(2008-06-20)     {1=>"a", 2=>"b"}
ruby-1.8.6p287(2008-08-11)     {1=>"a", 2=>"b"}
ruby-1.8.6head(2009-02-13p330) {1=>"a", 2=>"b"}
ruby-1.8.7p0(2008-05-31)       {1=>"a", 2=>"b"}
ruby-1.8.7p17(2008-06-09)      {1=>"a", 2=>"b"}
ruby-1.8.7p22(2008-06-20)      {1=>"a", 2=>"b"}
ruby-1.8.7p72(2008-08-11)      {1=>"a", 2=>"b"}
ruby-1.8.7head(2009-02-13p116) {1=>"a", 2=>"b"}
ruby-1.8(2009-02-05r22080)     {1=>"a", 2=>"b"}
ruby-1.9.1p0(2009-01-30r21907) {2=>"b", 1=>"a"}
ruby-1.9(2009-02-11r22240)     {2=>"b", 1=>"a"}
-- 
Tanaka Akira

2009/2/13 James Coglan <jcoglan@googlemail.com>:
>>
>>
>>> Seconded -- 1.8.7 is precisely where my code that was relying on insertion
>>> order *does not work*. Actually let me be more specific. My code was
>>> relying
>>> on keys being inserted in the order they appear in a hash literal, and on
>>> subsequent iteration occuring in the same order.
>>>
>>
>> That doesn't happen in any 1.8 version, though. (Sorry; I feel like
>> something's going right past me, and I'll stop after this iteration
>> :-)
>
>
>
> Regardless of whether they're *supposed* to, the Rubies I've used before
> 1.8.7 actually do iterate in insertion order.

NO THEY DO NOT. It is the nature of a regular hashtable that
the order of entries in its internal data structures depends
only on the hash function and its inputs. It doesn't know
anything about the order of entries in your hash literal.

I've shown you examples using Ruby *1.8.6* that clearly
demonstrate that it gives a **** about order of appearance
in a literal, or insertion order.

Stefan

Hi --

On Sat, 14 Feb 2009, James Coglan wrote:

>>
>>
>>> Seconded -- 1.8.7 is precisely where my code that was relying on insertion
>>> order *does not work*. Actually let me be more specific. My code was
>>> relying
>>> on keys being inserted in the order they appear in a hash literal, and on
>>> subsequent iteration occuring in the same order.
>>>
>>
>> That doesn't happen in any 1.8 version, though. (Sorry; I feel like
>> something's going right past me, and I'll stop after this iteration
>> :-)
>
>
>
> Regardless of whether they're *supposed* to, the Rubies I've used before
> 1.8.7 actually do iterate in insertion order. Could be machine/OS specific,
> a fluke, whatever. The point is that 1.8.7 definitely does not iterate in
> the order that keys appear in a literal, at least on my machine. If this is
> supposed to now be defined behaviour I'll investigate further and file a bug
> if necessary.

I think it probably is machine-dependent, or something like that. I've
never heard of hash order being anything but "not guaranteed" before
1.9 -- except that if you iterate twice, I believe it definitely
happens in the same order both times (though I'm not 100% sure that
that's actually specified or guaranteed either).


David

-- 
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2)

http://www.wishsight.com => Independent, social wishlist management!

[Note:  parts of this message were removed to make it a legal post.]

On Fri, Feb 13, 2009 at 10:14 AM, David A. Black <dblack@rubypal.com> wrote:

> Hi --
>
> On Sat, 14 Feb 2009, Rick DeNatale wrote:
>
>  Sometime after that discussion, Matz, who I know has much more than a
>> basic
>> understanding of hash-tables, decided that, yes,
>> defining the iteration order of Ruby hashes to  be by insertion order, and
>> that this was easily done with minimal impact to performance/space
>> requirements by linking buckets in the internal hash table used to
>> IMPLEMENT
>> Hash, and made this change in Ruby 1.9, which has been backported to Ruby
>> 1.8.7.
>>
>
> Hashes aren't ordered in 1.8.7, though.
>

Which makes this part of the thread rather moot, doesn't it?!

Thanks for pointing that out.
-- 
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale

[Note:  parts of this message were removed to make it a legal post.]

>
> > Regardless of whether they're *supposed* to, the Rubies I've used before
> > 1.8.7 actually do iterate in insertion order.
>
> NO THEY DO NOT. It is the nature of a regular hashtable that
> the order of entries in its internal data structures depends
> only on the hash function and its inputs. It doesn't know
> anything about the order of entries in your hash literal.
>
> I've shown you examples using Ruby *1.8.6* that clearly
> demonstrate that it gives a **** about order of appearance
> in a literal, or insertion order.



I'm really not up for a slanging match so let me just say that, in code I've
written, Ruby < 1.8.7 has demonstrated the behaviour I described. This may
be a fluke or a bug, in which case I will investigate further and file bugs
if necessary. What I do know is that I've had code in a library released
over 2 years ago and used by a fair number of people relying on this
behaviour and heard no complaints until 1.8.7 arrived. I realise that
hashtables are not ordered in 1.8 and have since made my code more robust.
I'm not questioning your examples -- you can but experiment to see what
works -- and I will try to extract the code from my project that
demonstrates my point when I have some time.

I'm not the least bit interested in who's right or wrong or in berating the
Ruby code devs or indeed anyone else, and was hoping for a productive
discussion, not people repeatedly asserting that I don't know how a hash
table works and trying to shut me up. When I've time I'll see if what I have
is a Ruby bug or something else. Until then I'm canning this conversation.

[Note:  parts of this message were removed to make it a legal post.]

On Fri, Feb 13, 2009 at 10:06 AM, M. Edward (Ed) Borasky
<zznmeb@gmail.com>wrote:

>
> 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.


Bad idea, IMHO.

This would mean that  Ruby 1.8.8, would be backwards compatible with Ruby
1.8.6, but NOT with Ruby 1.8.7, which might be good for needing to say with
the  Ruby 1.8.6 definition, but not those who are already using Ruby 1.8.7.


-- 
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale

Hi --

On Sat, 14 Feb 2009, James Coglan wrote:

> I'm really not up for a slanging match so let me just say that, in code I've
> written, Ruby < 1.8.7 has demonstrated the behaviour I described. This may
> be a fluke or a bug, in which case I will investigate further and file bugs
> if necessary.

It's not a bug; there was never any defined order behavior, so no
behavior is either right or wrong.


David

-- 
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2)

http://www.wishsight.com => Independent, social wishlist management!

+1 for the main question,
 but...


On Feb 11, 9:15=A0pm, Charles Oliver Nutter <charles.nut...@sun.com>
wrote:
> I still feel like Ruby 1.9 should have been 2.0.
> Then 1.8.7 could have been 1.9, 1.8.8 could be 1.10,
> and so on, ...

I also agree about this. Perhaps it isn't too late
to rename "1.9.1.0.0.1" to "2.0.0.0.1" ??

Also is it possible to make some "ruby20.rb" package
wich emulate some features of 1.9 present in 1.8.7?

Then in ruby-1.8.8 which would be 1.8.6 like
but would allow us to write:

   require 'ruby20'

Then all sugar features that are present in ruby 1.8.7
would be enable!
Perhaps this package could even be required from a 1.8.6
ruby version??

-- Maurice

P.S.
+1 for the original question ;-)

[Note:  parts of this message were removed to make it a legal post.]

On Fri, Feb 13, 2009 at 11:07 AM, David A. Black <dblack@rubypal.com> wrote:

> On Sat, 14 Feb 2009, James Coglan wrote:
> Regardless of whether they're *supposed* to, the Rubies I've used before
>
>> 1.8.7 actually do iterate in insertion order. Could be machine/OS
>> specific,
>> a fluke, whatever. The point is that 1.8.7 definitely does not iterate in
>> the order that keys appear in a literal, at least on my machine. If this
>> is
>> supposed to now be defined behaviour I'll investigate further and file a
>> bug
>> if necessary.
>>
>
> I think it probably is machine-dependent, or something like that. I've
> never heard of hash order being anything but "not guaranteed" before
> 1.9 -- except that if you iterate twice, I believe it definitely
> happens in the same order both times (though I'm not 100% sure that
> that's actually specified or guaranteed either).
>

No, it's in the absence of key collisions, it's really determined by the
hash values of the keys,  The iteration is over the hash buckets and hash
buckets marked as empty are skipped.

Consider your examples which I've excerpted:

% all-ruby -e 'h = {2=>"b", 1=>"a"}; p h'
...
ruby-1.8.6head(2009-02-13p330) {1=>"a", 2=>"b"}
...
ruby-1.8.7head(2009-02-13p116) {1=>"a", 2=>"b"}
...
ruby-1.9.1p0(2009-01-30r21907) {2=>"b", 1=>"a"}

Note that for Ruby 1.8.6 and 1.8.7, the iteration order is by the sort order
of the keys.  But that's just a side-effect of the hash of a fixnum being
just the internal immediate representation which happens to be n*2 + 1 for a
Fixnum n:

irb(main):001:0> 1.hash
=> 3
irb(main):002:0> 2.hash
=> 5

Had you used what is arguably the more natural order in the literal, i.e. {1
=> "a", 2 => "b"} it would appear as if iteration was by insertion order,
but that's just an accidental artifact.

I suspect that those who observed that Ruby 1.8.7 'preserves' insertion
order are looking at specific artificial cases like this.
-- 
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale

On Feb 13, 2009, at 3:53 AM, William James wrote:

> James Coglan 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.

I guess you haven't used Ruby 1.9.  :)

James Edward Gray II

On Feb 13, 2009, at 9:06 AM, M. Edward (Ed) Borasky wrote:

> 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. :)

 >> "1.8.9" < "1.8.10"
=> false

James Edward Gray II

Hi --

On Sat, 14 Feb 2009, Rick DeNatale wrote:

> On Fri, Feb 13, 2009 at 11:07 AM, David A. Black <dblack@rubypal.com> wrote:
>
>> On Sat, 14 Feb 2009, James Coglan wrote:
>> Regardless of whether they're *supposed* to, the Rubies I've used before
>>
>>> 1.8.7 actually do iterate in insertion order. Could be machine/OS
>>> specific,
>>> a fluke, whatever. The point is that 1.8.7 definitely does not iterate in
>>> the order that keys appear in a literal, at least on my machine. If this
>>> is
>>> supposed to now be defined behaviour I'll investigate further and file a
>>> bug
>>> if necessary.
>>>
>>
>> I think it probably is machine-dependent, or something like that. I've
>> never heard of hash order being anything but "not guaranteed" before
>> 1.9 -- except that if you iterate twice, I believe it definitely
>> happens in the same order both times (though I'm not 100% sure that
>> that's actually specified or guaranteed either).
>>
>
> No, it's in the absence of key collisions, it's really determined by the
> hash values of the keys,  The iteration is over the hash buckets and hash
> buckets marked as empty are skipped.
>
> Consider your examples which I've excerpted:
>
> % all-ruby -e 'h = {2=>"b", 1=>"a"}; p h'
> ...
> ruby-1.8.6head(2009-02-13p330) {1=>"a", 2=>"b"}
> ...
> ruby-1.8.7head(2009-02-13p116) {1=>"a", 2=>"b"}
> ...
> ruby-1.9.1p0(2009-01-30r21907) {2=>"b", 1=>"a"}
>
> Note that for Ruby 1.8.6 and 1.8.7, the iteration order is by the sort order
> of the keys.  But that's just a side-effect of the hash of a fixnum being
> just the internal immediate representation which happens to be n*2 + 1 for a
> Fixnum n:
>
> irb(main):001:0> 1.hash
> => 3
> irb(main):002:0> 2.hash
> => 5
>
> Had you used what is arguably the more natural order in the literal, i.e. {1
> => "a", 2 => "b"} it would appear as if iteration was by insertion order,
> but that's just an accidental artifact.

That's why I didn't :-)


David

-- 
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2)

http://www.wishsight.com => Independent, social wishlist management!

2009/2/13 James Coglan <jcoglan@googlemail.com>:
>>
>> > Regardless of whether they're *supposed* to, the Rubies I've used before
>> > 1.8.7 actually do iterate in insertion order.
>>
>> NO THEY DO NOT. It is the nature of a regular hashtable that
>> the order of entries in its internal data structures depends
>> only on the hash function and its inputs. It doesn't know
>> anything about the order of entries in your hash literal.
>>
>> I've shown you examples using Ruby *1.8.6* that clearly
>> demonstrate that it gives a **** about order of appearance
>> in a literal, or insertion order.
>
>
>
> I'm really not up for a slanging match so let me just say that, in code I've
> written, Ruby < 1.8.7 has demonstrated the behaviour I described. This may
> be a fluke or a bug, in which case I will investigate further and file bugs
> if necessary.

I can tell you how such a bug report would look like:

    Bug: In Ruby 1.8.x Hash iteration order .....

    Rejected: Hash iteration order in 1.8 is undefined.

> What I do know is that I've had code in a library released
> over 2 years ago and used by a fair number of people relying on this
> behaviour and heard no complaints until 1.8.7 arrived.

A hidden bug in your code because of an incorrect assumption.

> I realise that
> hashtables are not ordered in 1.8 and have since made my code more robust.
> I'm not questioning your examples -- ...

You seem to be ignoring them.

> ... you can but experiment to see what
> works -- and I will try to extract the code from my project that
> demonstrates my point when I have some time.
>
> I'm not the least bit interested in who's right or wrong or in berating the
> Ruby code devs or indeed anyone else, and was hoping for a productive
> discussion, not people repeatedly asserting that I don't know how a hash
> table works and trying to shut me up. When I've time I'll see if what I have
> is a Ruby bug or something else. Until then I'm canning this conversation.

I and others here took the trouble finding out and explaining
why your code failed. That's a productive discussion. You'd just
have to accept that it's your code that was buggy. There's
nothing bad about that. Everybody writes buggy code sometimes.

Instead you keep looking for a bug in Ruby that doesn't exist,
as has been clearly proven.

Stefan

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

There's a big difference between abstract computer science theory and pragmatic 
technology.

Ruby uses option-hashes as an emergent "named parameters" system. We have 
hundreds of DSLs written with them.

After these DSLs can see the order that the user-programmer wrote the 
parameters, they are free to use this order to grow more powerful.

-- 
   Phlip

James Coglan wrote:

> [Note:  parts of this message were removed to make it a legal
> post.]
> 
> > 
> > > Regardless of whether they're supposed to, the Rubies
> > > I've used before 1.8.7 actually do iterate in insertion
> > > order.
> > 
> > NO THEY DO NOT. It is the nature of a regular hashtable that
> > the order of entries in its internal data structures depends
> > only on the hash function and its inputs. It doesn't know
> > anything about the order of entries in your hash literal.
> > 
> > I've shown you examples using Ruby *1.8.6* that clearly
> > demonstrate that it gives a **** about order of appearance
> > in a literal, or insertion order.
> 
> 
> 
> I'm really not up for a slanging match so let me just say
> that, in code I've written, Ruby < 1.8.7 has demonstrated the
> behaviour I described. This may be a fluke or a bug, in which
> case I will investigate further and file bugs if necessary.
> What I do know is that I've had code in a library released
> over 2 years ago and used by a fair number of people relying
> on this behaviour and heard no complaints until 1.8.7
> arrived.

It's bad to write code that works by accident.
It's good to write code that works by design.

>            I realise that hashtables are not ordered in 1.8

Normal hash-tables are ordered nowhere, no-how, and no-way.

>  and
> have since made my code more robust.  I'm not questioning
> your examples -- you can but experiment to see what works --
> and I will try to extract the code from my project that
> demonstrates my point when I have some time.
> 
> I'm not the least bit interested in who's right or wrong or
> in berating the Ruby code devs or indeed anyone else, and was
> hoping for a productive discussion, not people repeatedly
> asserting that I don't know how a hash table works

Do you understand how a hash-table works?  Have you ever
implemented one?  Have you studied hash-table code written
by someone else?

A 9-year-old boy wanted to keep track of the color of his
toys.  He wrote "car: red" on a piece of paper which he then
put in a bag.  Then he did the same with "airplane: silver"
and "ball: blue".  Days later, he decided to review the data.
He reached into the bag and pulled out a slip.  It didn't
say "car"!  It was the slip with the color of the ball!
The slips were coming out in the wrong order!
Devestated, he began crying and ran to his mommy.

>                             and trying
> to shut me up. When I've time I'll see if what I have is a
> Ruby bug or something else. Until then I'm canning this
> conversation.

William James wrote:

> Normal hash-tables are ordered nowhere, no-how, and no-way.

> A 9-year-old boy wanted to keep track of the color of his
> toys.  He wrote "car: red" on a piece of paper which he then
> put in a bag.  Then he did the same with "airplane: silver"
> and "ball: blue".  Days later, he decided to review the data.
> He reached into the bag and pulled out a slip.  It didn't
> say "car"!  It was the slip with the color of the ball!
> The slips were coming out in the wrong order!

There's a big difference between abstract computer science theory and pragmatic 
technology.

Ruby uses option-hashes as an emergent "named parameters" system. We have 
hundreds of DSLs written with them.

After these DSLs can see the order that the user-programmer wrote the 
parameters, they are free to use this order to grow more powerful.

Just because one (technological) implementation of hash tables throws 
information away, that does not mean it was _required_ to throw that info away.

How about we give you your own special version, HashWithIndifferentOrder, that 
guarantees it randomizes key order?

And along the way, we can give you := for assignment, and = to test equality, 
because - you know - the = operator has always meant equality, not assignment.

-- 
   Phlip

William James wrote:
> James Coglan wrote:
> 
>> [Note:  parts of this message were removed to make it a legal
>> post.]
>>
>>>> Regardless of whether they're supposed to, the Rubies
>>>> I've used before 1.8.7 actually do iterate in insertion
>>>> order.
>>> NO THEY DO NOT. It is the nature of a regular hashtable that
>>> the order of entries in its internal data structures depends
>>> only on the hash function and its inputs. It doesn't know
>>> anything about the order of entries in your hash literal.
>>>
>>> I've shown you examples using Ruby *1.8.6* that clearly
>>> demonstrate that it gives a **** about order of appearance
>>> in a literal, or insertion order.
>>
>>
>> I'm really not up for a slanging match so let me just say
>> that, in code I've written, Ruby < 1.8.7 has demonstrated the
>> behaviour I described. This may be a fluke or a bug, in which
>> case I will investigate further and file bugs if necessary.
>> What I do know is that I've had code in a library released
>> over 2 years ago and used by a fair number of people relying
>> on this behaviour and heard no complaints until 1.8.7
>> arrived.
> 
> It's bad to write code that works by accident.
> It's good to write code that works by design.
> 
>>            I realise that hashtables are not ordered in 1.8
> 
> Normal hash-tables are ordered nowhere, no-how, and no-way.
> 
>>  and
>> have since made my code more robust.  I'm not questioning
>> your examples -- you can but experiment to see what works --
>> and I will try to extract the code from my project that
>> demonstrates my point when I have some time.
>>
>> I'm not the least bit interested in who's right or wrong or
>> in berating the Ruby code devs or indeed anyone else, and was
>> hoping for a productive discussion, not people repeatedly
>> asserting that I don't know how a hash table works
> 
> Do you understand how a hash-table works?  Have you ever
> implemented one?  Have you studied hash-table code written
> by someone else?
> 
> A 9-year-old boy wanted to keep track of the color of his
> toys.  He wrote "car: red" on a piece of paper which he then
> put in a bag.  Then he did the same with "airplane: silver"
> and "ball: blue".  Days later, he decided to review the data.
> He reached into the bag and pulled out a slip.  It didn't
> say "car"!  It was the slip with the color of the ball!
> The slips were coming out in the wrong order!
> Devestated, he began crying and ran to his mommy.

Um, how is bag["car"] implemented? How is this analogous with a hash? Do 
*you* understand how a hash-table works? (Yes, I know you do.)

-- 
       vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407

Pit Capitain wrote:
> 2009/2/12 Gregory Brown <gregory.t.brown@gmail.com>:
>> On Thu, Feb 12, 2009 at 1:59 PM, Pit Capitain <pit.capitain@gmail.com> wrote:
>>> Gregory, there is no Ruby 1.8 and has never been. There have been
>>> 1.8.0, 1.8.1, up to 1.8.7, each one differing from the others.
>>
>> You keep saying this but frankly, it's ridiculous.  Yes, you can find
>> changes.  In Ruby 1.8.7, you get clubbed over the head with them.
> 
> So we agree to disagree. Though I'd be interested in what you'd define
> as "Ruby 1.8". Is it 1.8.6? Why not 1.8.2? Does 1.8.5 qualify as being
> a "Ruby 1.8", despite the differences to 1.8.6?

Until now, it didn't matter. Most code written under 1.8.6 ran quite 
happily under 1.8.5 or 1.8.2, unless it exercised a few specific bugs or 
a few edge cases of feature enhancements.

Example: TCPSocket.new now accepts up to 4 arguments instead of just 2. 
However few people use the functionality (for binding to an explicit 
local IP and/or port). Those who do will need to run the later version 
of Ruby.

IMO, the biggest problem with 1.8.7 is that people are getting it 
installed by default (e.g. in newer Debian/Ubuntu systems). They are 
starting to write code using a whole heap of new features in 1.8.6, 
sometimes by accident. This code will not run on production 1.8.6 
platforms. Once library writers start doing this, it messes up the whole 
library ecosystem.
-- 
Posted via http://www.ruby-forum.com/.

Phlip wrote:
> Ruby uses option-hashes as an emergent "named parameters" system. We 
> have hundreds of DSLs written with them.

Granted.

> After these DSLs can see the order that the user-programmer wrote the 
> parameters, they are free to use this order to grow more powerful.

How so?

I honestly can't think of a case where I'd want to do that. If I wanted 
positional arguments, I'd use them. If I want named arguments, why do I 
care about their position?

> Just because one (technological) implementation of hash tables throws 
> information away, that does not mean it was _required_ to throw that 
> info away.

No, but it's very likely more efficient to do so, and the vast majority 
of hashes simply do not need that information.

> How about we give you your own special version, 
> HashWithIndifferentOrder, that guarantees it randomizes key order?

Because most hashes don't need them?

There are several OrderedHash implementations, some of them quite old, 
if you really want to depend on hash ordering.

> And along the way, we can give you := for assignment, and = to test 
> equality, because - you know - the = operator has always meant 
> equality, not assignment.

Ew. I see your point, but I find I do a lot more assignments than tests 
for equality, so I prefer less typing for that.

Also not sure what this has to do with the other discussion...

Ola Bini wrote:
> What about 1.8.6.1?

As much as I dislike the patchlevel concept, it would be very cumbersome 
to change it now and have a fourth digit. Rubyspec would have to change, 
other implementations would have to change...consider the patchlevel 
number as the fourth digit and just continue to increment it.

- Charlie

Nobuyoshi Nakada wrote:
> Hi,
> 
> At Fri, 13 Feb 2009 02:36:06 +0900,
> Rick DeNatale wrote in [ruby-talk:327919]:
>> Although, I'm at a loss as to what you'd use for the version number on the
>> first maintenance release.
> 
> 1.8.6-p###.

Agreed, just to make more noise about this. The p-numbers aren't great 
(they could have just been a fourth digit) but moving to a fourth digit 
now would cause mass confusion.

Which do I install, 1.8.6-p287 or 1.8.6.1?

- Charlie

M. Edward (Ed) Borasky wrote:
> 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.

IMHO, Engine Yard should not take over Ruby 1.8.6 to take it in new 
directions, they are just becoming 1.8.6 *maintainers*. I agree with 
Matz that any large-scale changes like REE or other stuff should still 
filter down the 1.8 mainline chain.

And look at it this way...the non-Japanese community has perhaps not had 
enough say in the direction of 1.8...we don't want to turn around and do 
the same thing. If EY becomes 1.8.6 maintainers, they should not repeat 
mistakes and make sure the rest of ruby-core and the Japanese Ruby 
community are on board with *all* 1.8.6 revisions.

- Charlie

2009/2/13 James Coglan <jcoglan@googlemail.com>:
> I'm really not up for a slanging match so let me just say that, in code I've
> written, Ruby < 1.8.7 has demonstrated the behaviour I described.

This is just not true. Period. And I can prove it.

This is an excerpt from a previous version of your code:

  DICTIONARY = RegexpGroup.new({
    :OPERATOR => /return|typeof|[\[(\^=,{}:;&|!*?]/.source,
    :CONDITIONAL => /\/\*@\w*|\w*@\*\/|\/\/@\w*|@\w+/.source,
    :COMMENT1 => /\/\/[^\n]*/.source,
    :COMMENT2 => /\/\*[^*]*\*+([^\/][^*]*\*+)*\//.source,
    :REGEXP => /\/(\\[\/\\]|[^*\/])(\\.|[^\/\n\\])*\/[gim]*/.source,
    :STRING1 => /\'(\\.|[^\'\\])*\'/.source,
    :STRING2 => /"(\\.|[^"\\])*"/.source
  })

You say that in 1.8.6 the iteration order of the resulting hash has
been the same as the order in the hash literal, but look at the
following output:

  puts DICTIONARY
  => (COMMENT1)|(COMMENT2)|(STRING1)|(STRING2)|(CONDITIONAL)|(OPERATOR)|(REGEXP)

As you can see, the iteration order is completely different from the
order in the hash literal. I really don't know what made you think
that 1.8.6 was using insertion order.

> What I do know is that I've had code in a library released
> over 2 years ago and used by a fair number of people relying on this
> behaviour and heard no complaints until 1.8.7 arrived.

Your code was working by accident. Read along:

> I realise that
> hashtables are not ordered in 1.8 and have since made my code more robust.

You noticed that the iteration order had changed in 1.8.7, so you
changed your code to:

  DICTIONARY = RegexpGroup.new.
    put(:OPERATOR,    /return|typeof|[\[(\^=,{}:;&|!*?]/.source).
    put(:CONDITIONAL, /\/\*@\w*|\w*@\*\/|\/\/@\w*|@\w+/.source).
    put(:COMMENT1,    /\/\/[^\n]*/.source).
    put(:COMMENT2,    /\/\*[^*]*\*+([^\/][^*]*\*+)*\//.source).
    put(:REGEXP,      /\/(\\[\/\\]|[^*\/])(\\.|[^\/\n\\])*\/[gim]*/.source).
    put(:STRING1,     /\'(\\.|[^\'\\])*\'/.source).
    put(:STRING2,     /"(\\.|[^"\\])*"/.source)

I don't know whether this change made a difference on 1.8.7. It
definitely had no effect on the iteration order, neither in 1.8.7 nor
in 1.8.6:

  puts DICTIONARY
  => (COMMENT1)|(COMMENT2)|(STRING1)|(STRING2)|(CONDITIONAL)|(OPERATOR)|(REGEXP)

Now you might say that on your machine and with your version of Ruby
the iteration order had been different and that in your environment
the iteration order still had been the same as the literal order. But
that is not true. Read on:

> I will try to extract the code from my project that
> demonstrates my point when I have some time.

No need to do that. I fixed some bugs in your code so that the
iteration order is really the same as the literal order:

  puts DICTIONARY
  => (OPERATOR)|(CONDITIONAL)|(COMMENT1)|(COMMENT2)|(REGEXP)|(STRING1)|(STRING2)

And guess what? Your code stopped working! Your code only works with
the iteration order of 1.8.6. The iteration order must be different
from insertion order, or else your code doesn't work.

Now please stop talking about 1.8.6 having some well defined property
that has been changed in 1.8.7. This simply is not true.

> I'm not the least bit interested in who's right or wrong or in berating the
> Ruby code devs or indeed anyone else, and was hoping for a productive
> discussion (...)

OK. You said in a previous post that you still had one problem with
regular expressions in 1.8.7. In reality, the bug had nothing to do
with regular expressions, but with ... guess what? ... the iteration
order of hashes. If you carefully build all the hashes in the same
order as those you got with Ruby 1.8.6, then all your tests are
working on both 1.8.6 and 1.8.7.

I don't know git, but if you tell me how, I can send you the two bug
fixes and the working hash sequences. I'd suggest that you take a
careful look at those sequences, whether they are as you want them to
be, because they look really weird.

Regards,
Pit

In article <a245658d0902131727k241af80ai195a5fe0b534a060@mail.gmail.com>,
  Pit Capitain <pit.capitain@gmail.com> writes:

> This is an excerpt from a previous version of your code:
>
>   DICTIONARY = RegexpGroup.new({
>     :OPERATOR => /return|typeof|[\[(\^=,{}:;&|!*?]/.source,
>     :CONDITIONAL => /\/\*@\w*|\w*@\*\/|\/\/@\w*|@\w+/.source,
>     :COMMENT1 => /\/\/[^\n]*/.source,
>     :COMMENT2 => /\/\*[^*]*\*+([^\/][^*]*\*+)*\//.source,
>     :REGEXP => /\/(\\[\/\\]|[^*\/])(\\.|[^\/\n\\])*\/[gim]*/.source,
>     :STRING1 => /\'(\\.|[^\'\\])*\'/.source,
>     :STRING2 => /"(\\.|[^"\\])*"/.source
>   })

Symbol#hash is fragile.

% ruby-1.8.6p287 -e 'p :a.hash' 
104738
% ruby-1.8.6p287 -e ':x; p :a.hash'
104818

The :x expression, which seems have no side-effect, affects
:a.hash.

This is because Symbol#hash depends on how many symbols
known when the symbol first appeared.

This value affects the bucket of a hash.  So it affects the
iteration order, until ruby 1.8.

It also depends on ruby version.

% all-ruby -e 'p :a.hash'
ruby-1.4.6(2000-08-16)         8593
ruby-1.6.0(2000-09-19)         2281742
ruby-1.6.1(2000-09-27)         2281742
ruby-1.6.2(2000-12-25)         2291982
ruby-1.6.3(2001-03-19)         2294030
ruby-1.6.4(2001-06-04)         2294030
ruby-1.6.5(2001-09-19)         2294030
ruby-1.6.6(2001-12-26)         2296078
ruby-1.6.7(2002-03-01)         2302222
ruby-1.6.8(2002-12-24)         2308366
ruby-1.8.0(2003-08-04)         2605326
ruby-1.8.1(2003-12-25)         2609422
ruby-1.8.2(2004-12-25)         2619662
ruby-1.8.3(2005-09-21)         2625806
ruby-1.8.4(2005-12-24)         2625806
ruby-1.8.5(2006-08-25)         104018
ruby-1.8.5p52(2007-06-07)      104178
ruby-1.8.5p113(2007-09-23)     104178
ruby-1.8.5p115(2008-03-03)     104178
ruby-1.8.5p231(2008-06-20)     104178
ruby-1.8.5head(2008-06-20p231) 104178
ruby-1.8.6p0(2007-03-13)       104738
ruby-1.8.6p36(2007-06-07)      104738
ruby-1.8.6p110(2007-09-23)     104738
ruby-1.8.6p111(2007-09-24)     104738
ruby-1.8.6p114(2008-03-03)     104738
ruby-1.8.6p230(2008-06-20)     104738
ruby-1.8.6p287(2008-08-11)     104738
ruby-1.8.6head(2009-02-13p330) 104738
ruby-1.8.7p0(2008-05-31)       109218
ruby-1.8.7p17(2008-06-09)      109218
ruby-1.8.7p22(2008-06-20)      109218
ruby-1.8.7p72(2008-08-11)      109218
ruby-1.8.7head(2009-02-13p116) 109218
ruby-1.8(2009-02-05r22080)     109938
ruby-1.9.1p0(2009-01-30r21907) 117848
ruby-1.9(2009-02-14r22297)     118088

It seems ruby-1.8.7 changes the value, as well as other many
versions.

The changes are because the number of symbols used
internally, algorithm changes, etc.

Symbol#hash is fragile.  Too dangerous to depend.

In general, the algorithm of #hash methods (not only
Symbol#hash) is ruby internal.  Don't depend on that.
-- 
Tanaka Akira

[Note:  parts of this message were removed to make it a legal post.]

>
> I don't know git, but if you tell me how, I can send you the two bug
> fixes and the working hash sequences. I'd suggest that you take a
> careful look at those sequences, whether they are as you want them to
> be, because they look really weird.



That would be wonderful, thank you. Just email patches to
jcoglan@googlemail.com, or send me an archive with all the working code if
diffs are a problem.

Seems I somehow gave the impression that I think my code is perfect and that
Ruby is broken. All I wanted to do was point out a change and ask for help
fixing my code. Shooting down assertions as untrue when they're based on
working code is not helpful. I realise it's easy to misappropriate the cause
of bugs sometimes but it's far more helpful to help the author investigate
the cause, rather than just telling them their examples are wrong and
questioning their knowledge. This list is usually in the friendly and
helpful end of the spectrum but this thread seems to have taken the tone
down a couple notches.

One final thing: someone mentioned that ordered hashes had been backported
to 1.8.7 but others disagree. Could someone from the core team settle this
one?

Hi --

On Sat, 14 Feb 2009, James Coglan wrote:

> One final thing: someone mentioned that ordered hashes had been backported
> to 1.8.7 but others disagree. Could someone from the core team settle this
> one?

1.8.7 can settle it :-)

irb(main):001:0> RUBY_DESCRIPTION
=> "ruby 1.8.7 (2008-08-11 patchlevel 72) [i386-solaris2.11]"
irb(main):002:0> {3,4,1,2}.first
=> [1, 2]


David

-- 
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2)

http://www.wishsight.com => Independent, social wishlist management!

On Feb 11, 12:10=A0pm, Gregory Brown <gregory.t.br...@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. =A0 If you agree with this, share your
> thoughts or at least a simple '+1'.

+1000

We have a reasonable-sized body of code on 1.8.7, in production, that
we will not expect to upgrade for a minor release.

We expect _some_ compatibility issues with an 1.8 -> 1.9 upgrade.

We expect there will be many issues with an 1.8 -> 2.0 upgrade.

I have been developing software and managing the development process
for almost 30 years, and this issue of an incompatible minor release
is a huge violation of the Principle of Least Surprise.

If this trend is followed, that of capriciously breaking compatibility
on minor point releases, then the language usage rate will diminish,
adoption rate will decrease, and the language will become
marginalized.

People only have so much time and effort to work on problems.  A
programming language is a tool to solve those problems.  If the tool
causes MORE work, then another tool will be chosen instead.

It's really pretty simple.

On Sat, Feb 14, 2009 at 10:03 AM, aks <alan.stebbens@gmail.com> wrote:
> On Feb 11, 12:10 pm, Gregory Brown <gregory.t.br...@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'.
>
> +1000
>
> We have a reasonable-sized body of code on 1.8.7, in production, that
> we will not expect to upgrade for a minor release.
>
> We expect _some_ compatibility issues with an 1.8 -> 1.9 upgrade.
>
> We expect there will be many issues with an 1.8 -> 2.0 upgrade.
>
> I have been developing software and managing the development process
> for almost 30 years, and this issue of an incompatible minor release
> is a huge violation of the Principle of Least Surprise.
>
> If this trend is followed, that of capriciously breaking compatibility
> on minor point releases, then the language usage rate will diminish,
> adoption rate will decrease, and the language will become
> marginalized.
>
> People only have so much time and effort to work on problems.  A
> programming language is a tool to solve those problems.  If the tool
> causes MORE work, then another tool will be chosen instead.
>
> It's really pretty simple.
>
>

Yeah ... my vote is for two *production* versions of the Ruby syntax
and semantics:

1. The current 1.8.6
2. The current 1.9.1

I think 1.8.7 was a failed experiment -- an evolutionary dead end --
that unfortunately got picked up by Linux distributors. I'm not sure
who else picked it up. Maybe that's the question we should be asking
-- who absolutely positively *must* have the Ruby 1.8.7 syntax and
semantics?

Also, please note that I specifically called out syntax and semantics.
I think platform-dependent optimizations, such as what Ruby Enterprise
Edition has for 32-bit Linux and what Sun has been doing with JRuby
are fair game. In fact, I encourage them and hope at some point to
have the free time to contribute a few to the 1.9.1 branch. :) And I
certainly agree with Matz that the Ruby Enterprise Edition
optimizations should somehow get into the main 1.8.x tree and not
continue to live on as a fork. As far as I know they're open source,
so it's "just a matter of merging patches." :)

I didn't make it to RubyConf 2008, but I was involved in 2006 and
2007, and I was under the impression that the planned "workflow" was
that the alternative implementers would stay with the 1.8.6 syntax and
semantics and that the core team would push ahead with the new syntax,
semantics and YARV engine, with a 1.9 intermediate release and a 2.0
"final" release. I think that's what Rubinius and JRuby have done,
although JRuby seems to have also embraced 1.9 as a fully-functional
implementation as well. I have no idea what's happening with IronRuby.
Is it even relevant any more?

So yes, my vote is for Ruby 1.8.8 to have Ruby 1.8.6 syntax and
semantics, all accumulated security patches, all accumulated bug fixes
and all accumulated platform-dependent optimizations to the MRI core.
But I'm only going to vote +1 because I'm trying to personally stay on
the 1.9.1 -> 2.0 branch.

-- 
M. Edward (Ed) Borasky

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

James Coglan wrote:
> Regardless of whether they're *supposed* to, the Rubies I've used before
> 1.8.7 actually do iterate in insertion order. Could be machine/OS specific,
> a fluke, whatever. The point is that 1.8.7 definitely does not iterate in
> the order that keys appear in a literal, at least on my machine. If this is
> supposed to now be defined behaviour I'll investigate further and file a bug
> if necessary.

They only appeared to be ordered in the cases you saw, especially in 
cases of smaller hashes (fewer possible permutations of unordered). They 
never were actually ordered. This is the Truth.

Naturally, unordered or "order unspecified" hashes may sometimes produce 
what seems to be ordered iteration. But it is entirely by chance.

And this has come up countless times...someone will iterate their 
three-element hash and it will come out in insertion order. Then they'll 
expand to a larger hash or a different implementation and it stops being 
ordered. They cry foul, ruby-talk intervenes, and they learn hashes are 
not ordered in 1.8.6.

I don't know what 1.8.7 does. 1.9.1 and JRuby (1.8.6 and 1.9.1 modes) 
both maintain hash keys in insertion order. Maintaining insertion order 
is simply a special case of unspecified ordering, so it's valid moving 
forward to *add* ordering, but not valid to take it away.

- Charlie

Hi,

At Thu, 12 Feb 2009 02:10:58 +0900,
Gregory Brown wrote in [ruby-talk:327704]:
> 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+

Could anyone summarize compatibility issues which really exist
now?

-- 
Nobu Nakada

2009/2/15 Nobuyoshi Nakada <nobu@ruby-lang.org>:
> At Thu, 12 Feb 2009 02:10:58 +0900,
> Gregory Brown wrote in [ruby-talk:327704]:
>> 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+
>
> Could anyone summarize compatibility issues which really exist
> now?

The only things I remember from this long discussion are:

* The new String#chars clashed with a method of Rails
  with the same name

* It is not allowed anymore to create new objects during
  garbage collection (the SWIG problem)

Both are at least questionable to being categorized as breaking
backwards compatibility and seem to have been fixed. Everything else
that had been said here and in other threads had to be withdrawn.

Regards,
Pit

Hi --

On Sun, 15 Feb 2009, Pit Capitain wrote:

> 2009/2/15 Nobuyoshi Nakada <nobu@ruby-lang.org>:
>> At Thu, 12 Feb 2009 02:10:58 +0900,
>> Gregory Brown wrote in [ruby-talk:327704]:
>>> 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+
>>
>> Could anyone summarize compatibility issues which really exist
>> now?
>
> The only things I remember from this long discussion are:
>
> * The new String#chars clashed with a method of Rails
>  with the same name
>
> * It is not allowed anymore to create new objects during
>  garbage collection (the SWIG problem)
>
> Both are at least questionable to being categorized as breaking
> backwards compatibility and seem to have been fixed. Everything else
> that had been said here and in other threads had to be withdrawn.

I would just add that most of the issues brought up about 1.8.7
(questions as to why a "stepping stone" to 1.9 is needed, the
unprecedented quantity of change for a teeny number (which I think is
not in dispute; the core team has said that a decision was made to
redefine the meaning of the numbering), the unprecedented amount of
backporting, the impact on non-MRI interpreters, and, in particular,
the dramatically increased likelihood that code being developed on the
later version (1.8.7) would be completely, deeply incompatible with
the earlier version (1.8.6)) -- these issues, and many of the others
that have been raised, are still there.

If it were all just a matter of a few bumps along the way in running
older code on the newer version, I'm sure we would not have been
having all these discussions. Lots of the people who perceive problems
have also gone through other 1.6 and 1.8 transitions; it's not a crowd
that likes to stir up problems for their own sake. So *something* is
different this time around. I hope we'll be able to move through it
smoothly and with creative solutions, but there are definitely
complexities to this set of transitions that were not present in every
previous transition.


David

-- 
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2)

http://www.wishsight.com => Independent, social wishlist management!

Hi,

At Sun, 15 Feb 2009 21:44:25 +0900,
Pit Capitain wrote in [ruby-talk:328269]:
> The only things I remember from this long discussion are:

Thank you.

> * It is not allowed anymore to create new objects during
>   garbage collection (the SWIG problem)

This is an old issue which has been already fixed.

-- 
Nobu Nakada

2009/2/15 David A. Black <dblack@rubypal.com>:
> I would just add that most of the issues brought up about 1.8.7
> (...) -- these issues, and many of the others
> that have been raised, are still there.

Yes, this is a nice summary of the concerns. Maybe I read Nobu's
question too limited when he asked about problems with backwards
compatibility. Maybe he meant general problems with adopting 1.8.7.
Thanks for the reminder.

Regards,
Pit

Hi --

On Sun, 15 Feb 2009, Pit Capitain wrote:

> 2009/2/15 David A. Black <dblack@rubypal.com>:
>> I would just add that most of the issues brought up about 1.8.7
>> (...) -- these issues, and many of the others
>> that have been raised, are still there.
>
> Yes, this is a nice summary of the concerns. Maybe I read Nobu's
> question too limited when he asked about problems with backwards
> compatibility. Maybe he meant general problems with adopting 1.8.7.

I'm probably just on auto-pilot :-) It feels like a kind of perfect
storm of small-to-medium issues, that emerge as one big issue, if that
makes sense.


David

-- 
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2)

http://www.wishsight.com => Independent, social wishlist management!