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

[F. Senault]

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 :
(irb):5: warning: already initialized constant RUBY_VERSION
=> "1.8.6"=> true

But not '1.8.10' > RUBY_VERSION, alas !



Fred

 

[Stefan Lang]

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

 

[Phlip]

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'

 

[Stefan Lang]

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

 

[James Coglan]

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

 

[David A. Black]

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!

 

[Stefan Lang]

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

 

[David A. Black]

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!

 

[James Coglan]

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

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

 

[Stefan Lang]

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

 

[Ezra Zygmuntowicz]

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
(e-mail address removed)

 

[Ola Bini]

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
(e-mail address removed)

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

 

[Gregory Brown]

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

 

[Rick DeNatale]

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

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.

 

[Gregory Brown]

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

 

[pat eyler]

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.

 

[James Coglan]

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

 

[James Gray]

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

 

[Ola Bini]

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

 

[pat eyler]

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