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

Ruby
61

In article [email protected],
Alex F. [email protected] 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.

62

Hi –

On Thu, 12 Feb 2009, Yossef M. wrote:

acceptable to break the existing code in the field which performed
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).

I think Charlie meant that a version comparison algorithm that didn’t
understand that “.10” was greater than “.9” was buggy.

David

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

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

63

On Feb 12, 4:21 am, Charles Oliver N. [email protected]
wrote:

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

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:

64

2009/2/11 James G. [email protected]:

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

65

Le 12 février à 15:25, Yossef M. 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 !

:slight_smile:

Fred

66

Stefan L. 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’

67

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.

68

On Fri, 13 Feb 2009, Stefan L. wrote:

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 (The Well-Grounded Rubyist)

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

69

2009/2/12 Phlip [email protected]:

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

70

2009/2/12 James C. [email protected]:

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

71

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 :slight_smile:

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 (The Well-Grounded Rubyist)

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

72

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:

73

2009/2/12 James C. [email protected]:

No monkey-patching on my part, just existing 1.8.6 behaviour that changed

Making Collection declarations more robust. Still got a concat bug on… · jcoglan/packr@9ece594 · GitHub

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

74

Engine Y. 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 Z.
[email protected]

75

On Thu, Feb 12, 2009 at 12:22 PM, Ezra Z. [email protected]
wrote:

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

76

Ezra Z. wrote:

the whole ruby community. Please respond here if you think Engine yard

+1.

–
Ola B. (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.

77

On Thu, Feb 12, 2009 at 12:22 PM, Ezra Z.
[email protected]wrote:

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

78

community. Please respond here if you think Engine yard would make good
maintainers of the ruby1.8.6 lineage

+1

Thanks,
Jan

79

On Thu, Feb 12, 2009 at 10:22 AM, Ezra Z. [email protected]
wrote:

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.

80

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