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

[Stefan Lang]

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

 

[M. Edward (Ed) Borasky]

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.

 

[Pit Capitain]

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.

"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

 

[Luis Lavena]

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,

 

[Robert Dober]

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

 

[Charles Oliver Nutter]

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

 

[James Coglan]

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

Hi --



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.

 

[David A. Black]

Hi --

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!

 

[Gnu Zoo]

The entire 1.8.x series should be backward compatible to 1.8.6 NOT
forward compatible to 1.9.x.

 

[Wayne Walker]

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

 

[William James]

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

 

[William James]

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.

 

[Nobuyoshi Nakada]

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?

 

[William James]

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.

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

 

[William James]

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

 

[Michal Suchanek]

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

 

[Michal Suchanek]

Hi,

In message "Re: If you are unhappy with the direction of Ruby 1.8.7+, respond"

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

I think he relied on the version/implementation specific behavior, so
1.8.7 HELPED to find a bug in HIS code, unless I am wrong in any ways.
Any other example of 1.8.7 incompatibility?

I am not happy with FUD-like attitude against 1.8.7. From my point of
view, 1.8.7 is a good release with unfortunate beginning. There are
slight incompatibility, but every past releases also had some sort of
incompatibilities as well. I'd like to use 1.8.7 to write new 1.8
code.

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

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

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

Thanks

Michal

 

[James Coglan]

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

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.

 

[Michal Suchanek]

Hi,

In message "Re: If you are unhappy with the direction of Ruby 1.8.7+, respond"


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

I expect you to be more concrete and specific about minor problems.

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

As far as I know:

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

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

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

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

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

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

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

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


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


If compatibility of 1.8.7 is really "not so great":

* if it is fixable, we can fix.

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

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

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

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

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

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

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

Thanks

Michal

 

[Pit Capitain]

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