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

[David Masover]

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.

 

[James Gray]

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

 

[David A. Black]

Hi --

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!

 

[Stefan Lang]

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

 

[M. Edward (Ed) Borasky]

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)

 

[Gregory Brown]

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

 

[Robert Dober]

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

 

[Rubén Medellín]

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

 

[Joel VanderWerf]

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

 

[Rupert Voelcker]

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

That'd be great!

Rupert

 

[Rick DeNatale]

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

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.

 

[pat eyler]

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)

 

[Nobuyoshi Nakada]

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

 

[Pit Capitain]

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

 

[Gregory Brown]

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

 

[Pit Capitain]

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

 

[Tom Copeland]

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

 

[Gregory Brown]

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.

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

 

[Phlip]

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?

 

[Joel VanderWerf]

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 .