Feature #4239: Let's begin a talk for "1.8.8" -- How's needed for surviving 1.8?

• Status: Closed
• Assignee: shyouhei (Shyouhei Urabe)
• Target version: Ruby 1.8.8

[sorah (Sorah Fukumori)]

=begin
###########################

This issue is translated from #4207.

For Japanese: This translation needs proofreading. If you have a patch, please send to sorah[at]tubusu[dot]net.

Newer version of translation available at: https://gist.github.com/b2c4f223d3ee0bca72ad

###########################

http://redmine.ruby-lang.org/issues/show/4207

= Let's begin a talk for "1.8.8" -- How's needed for surviving 1.8?

Hi,

I know that we cannot release ruby_1_8 branch... more than anyone.

But the time past 3 years from 1.9.0, and 2.5 years from 1.8.7;
it will be turned to 3 years in June 2011.

Why I'm marking "3 years," because releasing interval over 3 years
first time ever, and almost systems have revised after 3 years from
developed in my experience... so, almost codes which targets 1.8.7
preparing to revised; I think.

Well, Which version used when codes which targets 1.8.7 are revised,
I recommend 1.9.2 on my post, but almost can't use 1.9.x in
actuality. Like, Extension libraries doesn't work.
When can't use 1.9.x in codes, so it means use only 1.8.7. but it is
really tough, for making tasks with 1.8.7, and I think that when I
can give up maintaining 1.8.7? when my motivation is decreasing in
future, it won't increase again. So I want to use new version,
and don't use 1.8.7. New codes must target newer versions.

So, I want to set directions about 1.8.x future. I'm considing that
destroy ruby_1_8 branch and we won't release 1.8.8 for a one of
ideas. If we won't release 1.8.8, it means that can publish
announcement about 1.8.7 is last version of 1.8 branch,then 1.8
goes to last maintainance release. ah, in simplicity developers
task is decreased; developers will be happy.

P.S.: I hope that people in a posision like Endoh Yusuke at 1.9.2.
Anyone?

http://redmine.ruby-lang.org/issues/show/4207#note-6

Well, Organize this issue without my factors, currently we have the following
issues of 1.8.8.

• the time past 3 years from 1.9.0 released. In last 3 years, We released
  1.9.2 smoothly at 1.9 branch. Thanks Yugui (Yuki Sonoda).
  Also many users are using 1.9.x at forms of RailsDevCon.
  http://railsdevcon.jp/RailsDevCon2010report.pdf
• 1.8.8 (and 1.8.7?) is on migration step to 1.9, but if we continue
  developing 1.8.8 at this rate and release 1.8.8 in 2020, do users which
  haven't migrated to 1.9 exist?
• Currently does ruby_1_8 include any prompting structures to migrate
  1.9.x more than 1.8.7 at all? Just not merged same patches as 1.9?
• "I want to release so I release. Any users didn't effect." is a one of
  views, but it makes unhappy by recognition differences?

So.. Because 1.8 mustn't let be uncontrolled,
I propose the following ideas which possible:

1. Not today but ASAP, release 1.8.8 as "better 1.8.7." Release goal is this
   Summer.
2. Develop 1.8.8 until it's approached to ideal. Users can't be affect.
   Release goal is 2020 Christmas.
3. We won't release 1.8.8 never. Drop.
4. Otherwise I haven't thought yet.

I don't specify any idea for adoption.
Anyhow, I think that 1.8 mustn't keep current principle, so I asking "What do we do?"

Well.. what do we do?
=end

[headius (Charles Nutter)]

=begin
1.8.7 is a good release. It should be the last 1.8.x release. There's no need to make a "better" 1.8.7 in 1.8.8, because 1.8.7 is just fine.

1.9.2 is a good release. Anyone who wants something better than 1.8.7 should just move to 1.9.2. There's no reason to make a transitional 1.8.8 because 1.9.2 is just fine.

JRuby 1.6 will support both 1.8.7 and 1.9.2 modes, meaning that the second most-commonly used Ruby implementation will support 1.9.2. Therefore, there's no reason to make a 1.8.8 since the above two statements apply to JRuby as well as C Ruby. It would also require us to maintain a third mode, since so many users will depend on 1.8.7 logic of today.

1.8.8 is not needed, and I don't see JRuby ever supporting it. I vote to eliminate ruby_1_8 branch, make 1.8.7 and ruby_1_8_7 the last 1.8.x version, and continue to maintain it as a maintenance branch only. 1.9.2 and successors are the future.
=end

[sorah (Sorah Fukumori)]

=begin
On Mon, Jan 10, 2011 at 11:45 AM, Charles Nutter [e-mail] wrote:

1.8.7 is a good release. It should be the last 1.8.x release. There's no need to make a "better" 1.8.7 in 1.8.8, because 1.8.7 is just fine.

1.9.2 is a good release. Anyone who wants something better than 1.8.7 should just move to 1.9.2. There's no reason to make a transitional 1.8.8 because 1.9.2 is just fine.

JRuby 1.6 will support both 1.8.7 and 1.9.2 modes, meaning that the second most-commonly used Ruby implementation will support 1.9.2. Therefore, there's no reason to make a 1.8.8 since the above two statements apply to JRuby as well as C Ruby. It would also require us to maintain a third mode, since so many users will depend on 1.8.7 logic of today.

1.8.8 is not needed, and I don't see JRuby ever supporting it. I vote to eliminate ruby_1_8 branch, make 1.8.7 and ruby_1_8_7 the last 1.8.x version, and continue to maintain it as a maintenance branch only. 1.9.2 and successors are the future.

+1. Users should use 1.9 basically and they should switch to 1.8 via
RVM or some version switching methods when users have to run code
which can't run on 1.9.

--
Shota Fukumori a.k.a. @sora_h - http://codnote.net/

=end

[tenderlovemaking (Aaron Patterson)]

=begin
On Mon, Jan 10, 2011 at 11:47:14AM +0900, Charles Nutter wrote:

Issue #4239 has been updated by Charles Nutter.

1.8.7 is a good release. It should be the last 1.8.x release. There's no need to make a "better" 1.8.7 in 1.8.8, because 1.8.7 is just fine.

1.9.2 is a good release. Anyone who wants something better than 1.8.7 should just move to 1.9.2. There's no reason to make a transitional 1.8.8 because 1.9.2 is just fine.

JRuby 1.6 will support both 1.8.7 and 1.9.2 modes, meaning that the second most-commonly used Ruby implementation will support 1.9.2. Therefore, there's no reason to make a 1.8.8 since the above two statements apply to JRuby as well as C Ruby. It would also require us to maintain a third mode, since so many users will depend on 1.8.7 logic of today.

1.8.8 is not needed, and I don't see JRuby ever supporting it. I vote to eliminate ruby_1_8 branch, make 1.8.7 and ruby_1_8_7 the last 1.8.x version, and continue to maintain it as a maintenance branch only. 1.9.2 and successors are the future.

As a library maintainer, I have to agree with Charles. Dealing with
differences between 1.8.7, 1.8.8, and 1.9.2 is too much. I would like
to see 1.8.7 be the last release of Ruby 1.8.x.

I am really happy on Ruby 1.9.2, I don't want to see the 1.8.x series
drug out longer.

--
Aaron Patterson
http://tenderlovemaking.com/

Attachment: (unnamed)
=end

[zdavatz (Zeno Davatz)]

=begin
Hi

I believe that we do need a 1.8.8 Release. The simple reason for that is: Otherwise the Road to 1.9.2 will be to bumpy for many who want to do the switch from Ruby 1.8.6 to Ruby 1.9.2. We want to do that switch. But we do not want to break our Neck doing so.

A good example is the Oniguruma Patch. We need it in all our legacy applications. As Michael Fellinger points out here: http://url.ba/00z0 the Oniguruma Functions where not copied 100% into Ruby 1.9.2. Anybody who used the Oniguruma-Patch will expect the same functions in Ruby 1.9.2 - well and then they get burned as Michael Fellinger did. Implicitly this tells the user to jump over a huge crevasse. Releasing Ruby 1.8.8 will smoothen the jump to Ruby 1.9.2 for many loyal Ruby Users.

We are doing Ruby since over 10 years. Yui Naruse pointed out that Ruby 1.8.6 has become to stable. If that is so you could also say that the transition to Ruby 1.9.2 is still to impractical for many people. People are actually afraid to switch. The goal for Ruby should be to make it more practical for users to switch to Ruby 1.9.2. At the moment it seems like you are pushing people into to the Crevasse, watching as they drop. I think that is a reason why Lucas Nussbaum quit http://url.ba/vets

It is simply not possible for us to just "jump" to Ruby 1.9.2. Our codebase is to large. We have to switch slowly. By releasing 1.8.8 everybody will have an easier transition period and users will feel more compelled to switch to Ruby 1.9.2. At the same time Ruby 1.9.2 can catch up with 1.8.8 in the sense that it will at least support the same feature and more, not less. Take Oniguruma as an example.

I strongly believe that the Oniguruma Patch should be applied to Ruby 1.8.8 because of the above reasons. I do not understand why that patch was never applied to Ruby 1.8.6 in the first place. Oniguruma still provides many more functions then Ruby 1.9.2 does. Ruby 1.9.2 should build on the functions Oniguruma achieved because many people are already using Oniguruma in the very stable 1.8.6. Why breaks stuff that is working great?

Enterprises and normal users care about one thing: Consistency.

For further understanding I also wrote a blog post about this: http://just.do/2011/01/10/a-vote-for-ruby-1-8-8/

Matz says that consistency is not necessarily his goal. I think the clear decision should be when to be inconsistent. I believe the inconsistency should happen between Ruby 1.9 and 2.0. Not between Ruby 1.8.x and 1.9. The reason: Because being inconsistency should be communicated in advance.

If you look at the kernel release cycle then I think that is a good example. Linus releases a new Kernel version every few weeks. I boot into every new rc-release (that I pull from git) and in 98% of the cases my machine comes up. Linus explicitly says that he only accepts big changes and new features in rc1 releases and then distills those down up to rc8 and then he pushes out the new stable release. So people know: Be adventurous in rc1 but work towards being stable with rc8 because a stable release should be a stable release.

Think about the normal user. The average joe-normal-user. Do not make his life miserable. Help him upgrade to the great 1.9.2! Slowly.

Best
Zeno

PS: We do not use Rails.
=end

[drbrain (Eric Hodel)]

=begin
On Jan 10, 2011, at 23:59, Zeno Davatz wrote:

I believe that we do need a 1.8.8 Release. The simple reason for that is: Otherwise the Road to 1.9.2 will be to bumpy for many who want to do the switch from Ruby 1.8.6 to Ruby 1.9.2. We want to do that switch. But we do not want to break our Neck doing so.

In my experience the transition is not difficult.

A good example is the Oniguruma Patch. We need it in all our legacy applications. As Michael Fellinger points out here:http://url.ba/00z0 the Oniguruma Functions where not copied 100% into Ruby 1.9.2. Anybody who used the Oniguruma-Patch will expect the same functions in Ruby 1.9.2 - well and then they get burned as Michael Fellinger did. Implicitly this tells the user to jump over a huge crevasse. Releasing Ruby 1.8.8 will smoothen the jump to Ruby 1.9.2 for many loyal Ruby Users.

I don't need the Oniguruma patch in any of my 1.8 installs.

I don't see how you could reasonably expect features from a patch that applies to ruby 1.8 would be present in ruby 1.9.

We are doing Ruby since over 10 years. Yui Naruse pointed out that Ruby 1.8.6 has become to stable. If that is so you could also say that the transition to Ruby 1.9.2 is still to impractical for many people. People are actually afraid to switch. The goal for Ruby should be to make it more practical for users to switch to Ruby 1.9.2. At the moment it seems like you are pushing people into to the Crevasse, watching as they drop. I think that is a reason why Lucas Nussbaum quit http://url.ba/vets

If you haven't moved from 1.8.6 to 1.8.7 why would you move from 1.8.6 to 1.8.8?

It is simply not possible for us to just "jump" to Ruby 1.9.2. Our codebase is to large. We have to switch slowly.

I have several libraries that I have run on Ruby 1.9.0, 1.9.1, 1.9.2 and 1.9.3dev. Moving from 1.8 to 1.9 was not difficult as I ran my tests and changed my code to adapt. The changes were small.

Supporting 1.8.6, 1.8.7 and >= 1.9.1 has some minor complications involving special-case code. There were fewer complications when I switched to supporting 1.8.7 and >= 1.9.1 as 1.8.7 has backported many standard library additions from 1.9. (The major issue I have seen when trying to run code on 1.9 is the String#each removal.) (1.9.0 is ignored as it was a developer release and had no patchlevel releases.)

If you are writing an application you don't need to support multiple versions and having to add special-case code will not be a problem.

By releasing 1.8.8 everybody will have an easier transition period and users will feel more compelled to switch to Ruby 1.9.2.

I feel the opposite. By announcing end-of-life for 1.8 users will know that no further bug fixes or added features will be made.

At the same time Ruby 1.9.2 can catch up with 1.8.8 in the sense that it will at least support the same feature and more, not less. Take Oniguruma as an example.

I don't understand how adding features to a new 1.8 release will encourage users to switch to 1.9.2. Furthermore new features in a new release will require patchlevel releases and tie up developer resources maintaining 1.8 for many additional months.

I strongly believe that the Oniguruma Patch should be applied to Ruby 1.8.8 because of the above reasons. I do not understand why that patch was never applied to Ruby 1.8.6 in the first place. Oniguruma still provides many more functions then Ruby 1.9.2 does. Ruby 1.9.2 should build on the functions Oniguruma achieved because many people are already using Oniguruma in the very stable 1.8.6. Why breaks stuff that is working great?

Enterprises and normal users care about one thing: Consistency.

No Ruby 1.8 version has ever shipped with Oniguruma. Consistency states that Oniguruma should not be applied to any official 1.8.

For further understanding I also wrote a blog post about this: http://just.do/2011/01/10/a-vote-for-ruby-1-8-8/

Matz says that consistency is not necessarily his goal. I think the clear decision should be when to be inconsistent. I believe the inconsistency should happen between Ruby 1.9 and 2.0. Not between Ruby 1.8.x and 1.9. The reason: Because being inconsistency should be communicated in advance.

The inconsistencies between 1.8 and 1.9 were clear to me well in advance and I believe were adequately communicated.

If you look at the kernel release cycle then I think that is a good example. Linus releases a new Kernel version every few weeks. I boot into every new rc-release (that I pull from git) and in 98% of the cases my machine comes up. Linus explicitly says that he only accepts big changes and new features in rc1 releases and then distills those down up to rc8 and then he pushes out the new stable release. So people know: Be adventurous in rc1 but work towards being stable with rc8 because a stable release should be a stable release.

Think about the normal user. The average joe-normal-user. Do not make his life miserable. Help him upgrade to the great 1.9.2! Slowly.

Nobody is forcing you to move to 1.9.2. You can take as long as you like. I have not found major difficulty in moving to 1.9.2. Most libraries I have just work on 1.9.2. Those that do not have only required minor changes.

However, I am slowly abandoning 1.8 as a library author and maintainer. I see little need to test or develop against 1.8.

=end

[sorah (Sorah Fukumori)]

=begin

This is translation from

Akinori MUSHA's mail at http://redmine.ruby-lang.org/issues/show/4207#note-11

This translation needs proofreading. The latest translation is here:

https://gist.github.com/b2c4f223d3ee0bca72ad#file_3.txt

Sorry for that I haven't join to this discussion because of busy.

I think the following issues for release ruby 1.8.8 from current ruby 1.8.8dev.

1. Make 1.8 implementation MRI only

   People shouldn't need supporting 1.8 othar than MRI.
   But in actual, JRuby is continuing to support 1.8, and JRuby community
   doesn't think well for 1.8.8.

   If we'll release 1.8.8, we doesn't require supporting 1.8.8 to other
   implementations, and I thought that start working at 1.8.8 after other ruby
   implementations finish supporting 1.8(.7). But I'm disappointed because I
   heard that JRuby's 1.9 supporting level is not completed yet,and I thought
   that stop discussion about 1.8.8 until the background moves. (Froze we
   release 1.8.8 or not.)

   Matters of that someone needs MRI 1.8 are already raised, I don't add more.
   But if we'll release 1.8.8, that is for peoples who needs 1.8.8, so
   any opinions like "Don't need" don't effect to releasing.

   But, we mustn't occur problems by releasing 1.8.8. Like users which using
   1.8.8 post project which already migrated to 1.9 an opinion about
   corresponding to 1.8.8. To avoid this, we have to take a clear the following
   issues, and make those for causes.

2. Implement features for compatibility with ruby1.9.2

   • 1.9.2+ compatibility warnings; like occur by default.
   • Occur warning when Block variable name and Local variable name are equal
   • magic comment; occur warning when doesn't equal with $KCODE
   • Splat syntax (like [a, *b, c] ) when not tail of list.
   • ->(args){...} #=> Proc syntax

   (Raise more if have more features)

3. Test compatibility with ruby 1.8.7

   • Test left and right with RubySpec, 3rd-party gems, in-house apps

   • Report for bug if code works well at 1.8.7, but doesn't work at 1.8.8

     Some inadequacy compatibility codes and some forceful monkey patches
     don't work well, but we supports fixing them.

Many time needs for working with the above issues, so we need manpower with
avidity. If we can't take it, same as current, so 1.8 users use 1.8.7,
or 1.8 users which have different needing use 1.8.8dev and maintain 1.8.8dev
by voluntary developers.

... It is essence of my thinking.

Thanks.
=end

[headius (Charles Nutter)]

=begin
JRuby's 1.9 support is perhaps not complete, but it's good enough that we can run a very high percentage of RubySpecs, most Rails tests, and Rails itself is able to generate, scaffold, boot, and serve dynamic pages. It's looking very good.

If we get a lot of help from users (and maybe help from ruby-core), it may be possible to set 1.9 mode as the default mode for JRuby in the next release. I believe that would help 1.9 adoption and help age out 1.8.
=end

[zdavatz (Zeno Davatz)]

=begin
Dear Eric

Thanks for your reply.

01/11/2011 08:15 PM - reply to Eric Hodel

So why was the Oniguruma-Patch never applied to 1.8.7 or 1.8.6 but then "some" functions of Oniguruma where copied to 1.9.2 but just "some". It seems that you really do not use regular expressions. We do use regular expressions in our own code because we have to parse lots of data (PDF files, XLS files, Wordfiles, XML files, etc.) and we have to detect patterns because that is what Ruby is good at. We really need regular expression as does Michael Fellinger. And Fellinger got burned. Read the post I linked above http://url.ba/00z0

So what do you suggest, just wait until Ruby 1.9.2 covers all the features 1.8.6 with Oniguruma does? That patch is one great Patch. It should have been applied from the very beginning. Instead in the Fellinger Post Yui Naruse says that it was never the intention to copy all the functions of the Oniguruma-Patch.

Here comes one guy that writes a great patch for Ruby and then he is ignored, well at least partially. Maybe you can point me to a discussion where the decision was taken, that the Oniguruma Patch should not be applied to 1.8.6 or 1.8.7. I would be very interested to read more about that decision.

What I am trying to say is that Ruby 1.9.2 should be moved closer to 1.8.6 via 1.8.8. That gap has to be narrowed so people do not fall into the crevasse, walking on the glacier. At the moment switching to Ruby 1.9.2 feels a bit like Russian Roulette ;) some fun, some adventure. Well I would prefer if it would be a grandma game. Russian Roulette should be played in 2.0.

I think it is very telling if Yui Naruse says Ruby 1.8.6 has become to stable. That is what 1.9.2 should become in the future but with more features and more options. To smoothen that transition you need a pole in the middle that should be 1.8.8.

Just help the Grandma over the crevasse please. And there are lots of grandmothers out there. More then you think there are.

Best
Zeno
=end

[zimbatm (zimba tm)]

=begin
2011/1/12 Zeno Davatz [e-mail]:

So why was the Oniguruma-Patch never applied to 1.8.7 or 1.8.6 but then "some" functions of Oniguruma where copied to 1.9.2 but just "some". It seems that you really do not use regular expressions. We do use regular expressions in our own code because we have to parse lots of data (PDF files, XLS files, Wordfiles, XML files, etc.) and we have to detect patterns because that is what Ruby is good at. We really need regular expression as does Michael Fellinger. And Fellinger got burned. Read the post I linked above http://url.ba/00z0
[snip]

Look. ruby-1.9.2 happens to have another regexp engine, but it's
backward-compatible with 1.8.7, what do you want more ? The confusion
came because the onuguruma GEM was declaring to be forward-compatible
with 1.9.2, which is not.

If your parsing is so complicated that you need to use all the power
of oniguruma, then I suggest that you use the gem, or re-think your
solution to use a context-free parser like Trollop or Parslet.

In any cases, if 1.9 has some backward-incompatible changes, then no
1.8.X release can smooth the path more out. The current release is
really good. Now it's time for you to do the rest of the work and do
the transition :) If you want to be helpful, then make a list of
things that break during the transition.

=end

[headius (Charles Nutter)]

=begin
On Wed, Jan 12, 2011 at 3:52 PM, Jonas Pfenniger (zimbatm)
[e-mail] wrote:

Look. ruby-1.9.2 happens to have another regexp engine, but it's
backward-compatible with 1.8.7, what do you want more ? The confusion
came because the onuguruma GEM was declaring to be forward-compatible
with 1.9.2, which is not.

FWIW, both JRuby and Rubinius are using "Oniguruma all the time", and
we have had no problem matching compatibility with 1.8. Any
differences in 1.9 are really designed differences in Ruby, not in
Oniguruma (with a few small exceptions, of course).

• Charlie

=end

[naruse (Yui NARUSE)]

=begin
Hi,

(2011/01/13 6:52), Jonas Pfenniger (zimbatm) wrote:

2011/1/12 Zeno [e-mail]:

So why was the Oniguruma-Patch never applied to 1.8.7 or 1.8.6 but then

Because 1.8.6 and 1.8.7 are maintenance branch.
Only bug fixes are backported to them.

Shyouhei Urabe, the maintainer of 1.8.7, said about this in [ruby-core:34051].

"some" functions of Oniguruma where copied to 1.9.2 but just "some".

Oniguruma patch is Oniguruma 2.x and only a regexp engine.

But 1.9.2's regexp is not a copy of Oniguruma patch.
It is a fork of original Oniguruma 5.x.
Moreover the forked Oniguruma is the base framework of Ruby M17N
(multilingual support of Ruby).

They are different things.

It seems that you really do not use regular expressions.
We do use regular expressions in our own code because we have to parse
lots of data (PDF files, XLS files, Wordfiles, XML files, etc.) and we
have to detect patterns because that is what Ruby is good at. We really
need regular expression as does Michael Fellinger. And Fellinger got burned.
Read the post I linked above http://url.ba/00z0
[snip]

Look. ruby-1.9.2 happens to have another regexp engine, but it's
backward-compatible with 1.8.7, what do you want more ? The confusion
came because the onuguruma GEM was declaring to be forward-compatible
with 1.9.2, which is not.

If your parsing is so complicated that you need to use all the power
of oniguruma, then I suggest that you use the gem, or re-think your
solution to use a context-free parser like Trollop or Parslet.

In any cases, if 1.9 has some backward-incompatible changes, then no
1.8.X release can smooth the path more out. The current release is
really good. Now it's time for you to do the rest of the work and do
the transition :) If you want to be helpful, then make a list of
things that break during the transition.

My comment is the same as Jonas' one.

As I said above, Oniguruma patch and 1.9.2's regexp are different things.
And as you know (for example Michael's case), they are some incompatibility.
So if Oniguruma patch is included in 1.8.8, people will suffer from the
incompatibility.
Such one won't be a bridge from 1.8 to 1.9.

--
NARUSE, Yui [e-mail]

=end

[zdavatz (Zeno Davatz)]

=begin
Dear Yui-san

Thank you for your reply.

1. Can you please point me to the discussion, where Ruby-Core decided not to apply the Oniguruma-Patch in the first place to Ruby 1.8.7? Why was the patch never applied to Ruby 1.8.7 in the first place. Is there a discussion about that? I could not find anything so far. I am really interested to understand that decision better. You can also send me a Japanese Link, not a problem.

2. I get your argument but it does not seem chronologically logical to me. The Oniguruma-Patch for Ruby 1.8.6 was first. So I really do not understand why that patch was not applied in 1.8.7? What are the reasons for that?

3. Think consistency. I think Ruby should really try hard to be consistent. Again you come with the argument, that 1.9.2 regexp is not a copy of the Oniguruma Patch. Understood. But the case of Michael Felling shows that people first used Oniguruma and then they upgrade to Ruby 1.9.2 and then they see that Ruby 1.9.2 has regexp but is not 100% compatible with the Oniguruma Patch. But: The Oniguruma Patch was first and the people got used to that.

4. What I am trying to say is that Ruby-1.8.8 should smoothen that gap. Michael Fellinger clearly states that his problem is "one out of many and the shortest he could find". http://url.ba/uskq

5. My suggestion would be to apply the Patch for Ruby 1.8.8 and see to it that Ruby 1.9.2 covers 1.8.8 and does even more regexp then 1.8.8 - not less.

Slight off-Topic-Note: Consistency is really important for enterprise users. It is really key. I think Ruby should care about enterprise users too. Enterprise users are the "grandmothers" of the business.

Best
Zeno
=end

[naruse (Yui NARUSE)]

=begin
(2011/01/16 0:11), Zeno Davatz wrote:

1. Can you please point me to the discussion, where Ruby-Core decided
   not to apply the Oniguruma-Patch in the first place to Ruby 1.8.7?
   Why was the patch never applied to Ruby 1.8.7 in the first place. Is
   there a discussion about that? I could not find anything so far. I am
   really interested to understand that decision better. You can also
   send me a Japanese Link, not a problem.

As far as I know, no such discussion.
Without discussion, we won't apply the patch to Ruby 1.8.7
because Ruby 1.8.7 is maintenance branch.
We won't merge any new feature to maintenance branchon current policy.

2. I get your argument but it does not seem chronologically logical
   to me. The Oniguruma-Patch for Ruby 1.8.6 was first. So I really do
   not understand why that patch was not applied in 1.8.7? What are the
   reasons for that?

I couldn't understand this.
This maybe from your misunderstanding relating 3.

3. Think consistency. I think Ruby should really try hard to be
   consistent. Again you come with the argument, that 1.9.2 regexp is
   not a copy of the Oniguruma Patch. Understood. But the case of
   Michael Felling shows that people first used Oniguruma and then
   they upgrade to Ruby 1.9.2 and then they see that Ruby 1.9.2 has
   regexp but is not 100% compatible with the Oniguruma Patch. But: The
   Oniguruma Patch was first and the people got used to that.

The first time when ruby meets Oniguruma is the year 2002.
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-dev/16196

Can this an answer?

4. What I am trying to say is that Ruby-1.8.8 should smoothen that
   gap. Michael Fellinger clearly states that his problem is "one out of
   many and the shortest he could find". http://url.ba/uskq

I can't understand how Ruby 1.8.8 smooths the migration.
Could you show the logic?

5. My suggestion would be to apply the Patch for Ruby 1.8.8 and see
   to it that Ruby 1.9.2 covers 1.8.8 and does even more regexp then
   1.8.8 - not less.

Your suggestion seems:

• we should release Ruby 1.8.8
• Ruby 1.8.8 should include the Oniguruma Patch
• The included feature must compatible with 1.9.2

I must add one more requirement:

• the Ruby 1.8.8 regexp must be compatible with 1.8.7

Slight off-Topic-Note: Consistency is really important for enterprise
users. It is really key. I think Ruby should care about enterprise
users too. Enterprise users are the "grandmothers" of the business.

I think they are Rails users.
Their answer is showed by Rails 3.

--
NARUSE, Yui [e-mail]

=end

[duerst (Martin Dürst)]

=begin
I don't know much of the details/history here, but maybe a few comments
can help.

On 2011/01/16 3:05, NARUSE, Yui wrote:

(2011/01/16 0:11), Zeno Davatz wrote:

1. Can you please point me to the discussion, where Ruby-Core decided
   not to apply the Oniguruma-Patch in the first place to Ruby 1.8.7?
   Why was the patch never applied to Ruby 1.8.7 in the first place. Is
   there a discussion about that? I could not find anything so far. I am
   really interested to understand that decision better. You can also
   send me a Japanese Link, not a problem.

As far as I know, no such discussion.

That would make sense. After all, there are millions of
features/libraries/whatnot that are not included in Ruby, and it would
be much too much work to discuss all of them.

Slight off-Topic-Note: Consistency is really important for enterprise
users. It is really key.

Yes. So as an enterprise user, if you want to use special features that
are not in any version of Ruby, please don't blame Ruby for that.
Consistency doesn't mean consistency with all the patches you applied.

Regards, Martin.

--
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp mailto:[e-mail]

=end

[RickDeNatale (Rick DeNatale)]

=begin
On Sat, Jan 15, 2011 at 1:05 PM, NARUSE, Yui [e-mail] wrote:
in response to Zeno Davatz:

Your suggestion seems:

• we should release Ruby 1.8.8
• Ruby 1.8.8 should include the Oniguruma Patch
• The included feature must compatible with 1.9.2

I must add one more requirement:

• the Ruby 1.8.8 regexp must be compatible with 1.8.7

Slight off-Topic-Note: Consistency is really important for enterprise
users. It is really key. I think Ruby should care about enterprise
users too. Enterprise users are the "grandmothers" of the business.

I think they are Rails users.
Their answer is showed by Rails 3.

I'm definitely not in favor of bringing more 1.9.x features to the
1.8.x branch whether x is 6, 7, 8 or ...

But I think what 'enterprise' users are really looking for is a
rational relationship between minor versions and breaking changes. viz
http://semver.org/

It's water under the bridge, but 1.8.7 introduced several things which
broke applications and gems built using 1.8.6. This was a major
factor in most rails developers staying on 1.8.6 and Engine Yard
taking on the maintenance of 1.8.6. It was also problematic because
most re-packagers (like debian/ubuntu and I believe the RPM packagers)
take the same interpretation as the semantic versioning described
above, so they have separate packages for 1.8 and 1.9, but NOT for
1.8.6 and 1.8.7.

By now the breakage caused by 1.8.7 has mostly been healed and Rails
and the popular gems have caught up, and app developers for the most
part have either updated the app code to be 1.8.7 compatible, or have
frozen on 1.8.6 and gone silent.

And newly written Rails apps are using either 1.8.7 or 1.9.2.

But I'd hate to repeat that history with 1.8.8, it should not
introduce changes which break 1.8.7 apps, and it's hard to predict
what breaks apps in general, so it needs to take an overly
conservative approach IMHO.

--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Github: http://github.com/rubyredrick
Twitter: @RickDeNatale (Rick DeNatale)
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

=end

[naruse (Yui NARUSE)]

=begin
(2011/01/17 1:49), Rick DeNatale wrote:

But I think what 'enterprise' users are really looking for is a
rational relationship between minor versions and breaking changes. viz
http://semver.org/

FYI, our semantic versioning spec for Ruby 1.x is for example Ruby 1.9.2-p136,
Major = 1.9
Minor = 2
Patch = 136

--
NARUSE, Yui [e-mail]

=end

[RickDeNatale (Rick DeNatale)]

=begin
On Sun, Jan 16, 2011 at 12:19 PM, NARUSE, Yui [e-mail] wrote:

(2011/01/17 1:49), Rick DeNatale wrote:

But I think what 'enterprise' users are really looking for is a
rational relationship between minor versions and breaking changes. viz
http://semver.org/

FYI, our semantic versioning spec for Ruby 1.x is for example Ruby
1.9.2-p136,
Major = 1.9
Minor = 2
Patch = 136

Which really is at odds with the way most packagers and users of
packages think of things. I can't think of any other use of a 2 level
major version 'number'.

Now I know that the Ruby core team seems to have an aversion to having
version components as anything but a single decimal digit, but lots of
other software components are quite happy having version 2.6.37 or
2.6.35.10.

I know what the Ruby version scheme is, but I also understand that it
has been a source of unfortunate occurrences because guys like linux
packagers expect the versions to work like most of the other things
they package.

--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Github: http://github.com/rubyredrick
Twitter: @RickDeNatale (Rick DeNatale)
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

=end

[naruse (Yui NARUSE)]

=begin
(2011/01/17 3:26), Rick DeNatale wrote:

On Sun, Jan 16, 2011 at 12:19 PM, NARUSE, [e-mail] wrote:

(2011/01/17 1:49), Rick DeNatale wrote:

But I think what 'enterprise' users are really looking for is a
rational relationship between minor versions and breaking changes. viz
http://semver.org/

FYI, our semantic versioning spec for Ruby 1.x is for example Ruby
1.9.2-p136,
Major = 1.9
Minor = 2
Patch = 136

Which really is at odds with the way most packagers and users of
packages think of things. I can't think of any other use of a 2 level
major version 'number'.

This is mainly because of historical reason.
I personally think it should be changed in 2.0.

Now I know that the Ruby core team seems to have an aversion to having
version components as anything but a single decimal digit, but lots of
other software components are quite happy having version 2.6.37 or
2.6.35.10.

Your example seemsLinux kernel's version, and it seems:
Major = 2.6
Minor = 35
Patch = 10

I know what the Ruby version scheme is, but I also understand that it
has been a source of unfortunate occurrences because guys like linux
packagers expect the versions to work like most of the other things
they package.

--
NARUSE, Yui [e-mail]

=end

[zdavatz (Zeno Davatz)]

=begin
Dear Yui-san

Thank you for your reply.

First of all I do not want to blame anyone. I want to understand and improve.

No such discussion, that is interesting but according to http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-dev/16196
Oniguruma was introduced in 2002. So there is my question. Somebody introduces a very useful new feature in 2002, people start building on that but the real patch is never applied. Instead in Version 1.9.2 some features are copied from Oniguruma but not all. This scares the living frogs out of Grandmothers ;) and enterprises.

That is what does not make sense to me. That is what I mean by Chronologically logical. The Oniguruma-Features where introduced in 2002 but never made it into the main code. But obviously many people used it. 1.8.6 became very stable because important features where not merged in? I am asking a stupid rhetorical question here: Was the merging to timid then? Was the release cycle too long? That is what I like about the kernel release cycle. You know when to be timid and when to be courageous with new features (it took Linus a lot of effort to get there). Here you see how Linus merges a brand new feature right after 2.6.37: http://url.ba/2dam - very aggressive. 2.6.38-rc8 will be the opposite, very timid.

Yui Naruse wrote:

I must add one more requirement:

• the Ruby 1.8.8 regexp must be compatible with 1.8.7

As far as I can tell 1.8.8 with the Oniguruma-Patch would be compatible. And it would also be a bridge to 1.9.2. I guess the problem is more that 1.9.2 would have to catch up with 1.8.8 in terms of Regexp. But that is less of a problem because 1.8.6 is still "tooo" stable ;). And I consider that a compliment as many enterprises are still using 1.8.6.

Yui Naruse wrote:

I think they are Rails users.
Their answer is showed by Rails 3.

Well, Enterprise users want to depend on Ruby not on a App that is build with Ruby. We do not build on Rails. We build on Ruby. But sure, Ruby on Rails is the "RedHat" of Ruby (but it should not be considered the only one).

So I am with Rick but I think it is not just the numbers it is also the timing cycle and it is Oniguruma.

Actually I would also like to ask the question literally: Why does Matz say/think Ruby does not haveto/should not be consistent? http://bit.ly/Y1bQT - Can you point me to a current or old policy in respect to consistency of Ruby?

Thank you for your time.

Best
Zeno
=end

[spatulasnout (B Kelly)]

=begin
Rick DeNatale wrote:

It's water under the bridge, but 1.8.7 introduced several things which
broke applications and gems built using 1.8.6.

We had a lengthy thread a couple years ago, wherein folks attempted to
isolate precisely which changes in 1.8.7 introduced incompatibilities
with 1.8.6:

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/21997

By the end of the thread, there seemed to be exactly two issues:

• 1.8.7 String#chars conflicted with ActiveSupport's String#chars
  (Resolved by a patch to ActiveSupport)

• Allocation of new objects during garbage collection in C extensions
  now caused segfaults.
  (Mitigated by a patch to gc.c to abort with rb_bug at the point of
  allocation, instead of segfault later.)

Perhaps I'm making a small point, but it seems to me that when we say
that 1.8.7 introduced several incompatibilities, the ensuing
discussion has tended to focus on how to introduce fewer
incompatibilities in future releases.

Which I think in a way distracts from the reality that it was
apparently just TWO issues which caused all the ruckus.

(And which in a roundabout way makes me wonder what the point of a
1.8.8 release could be, given the apparent need to drastically
constrain the scope of changes between 1.8.7 and 1.8.8.)

But, if there is to be a 1.8.8 release, it would seem that it will
need to have precisely zero backward compatibility issues with
1.8.7, as we've seen the uproar that can be caused by just two such
issues.

Regards,

Bill

=end

[naruse (Yui NARUSE)]

=begin
Hi,

2011/1/17 Zeno Davatz [e-mail]:

No such discussion, that is interesting but according to http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-dev/16196
Oniguruma was introduced in 2002. So there is my question. Somebody introduces a very useful new feature in 2002, people start building on that but the real patch is never applied. Instead in Version 1.9.2 some features are copied from Oniguruma but not all. This scares the living frogs out of Grandmothers ;) and enterprises.

The year 2002 is the night before 1.8 is released, so we decided to
import Oniguruma in 1.9.
And the time Oniguruma is introduced on the main stage is not 1.9.2.
It is 1.9.0 in 2007.

That is what does not make sense to me. That is what I mean by Chronologically logical. The Oniguruma-Features where introduced in 2002 but never made it into the main code. But obviously many people used it. 1.8.6 became very stable because important features where not merged in?

Do you know Oniguruma gem? http://oniguruma.rubyforge.org/

I am asking a stupid rhetorical question here: Was the merging to timid then? Was the release cycle too long? That is what I like about the kernel release cycle. You know when to be timid and when to be courageous with new features (it took Linus a lot of effort to get there). Here you see how Linus merges a brand new feature right after 2.6.37: http://url.ba/2dam - very aggressive. 2.6.38-rc8 will be the opposite, very timid.

Did you read http://svn.ruby-lang.org/repos/ruby/tags/v1_8_7/NEWS ?

Yui Naruse wrote:

I must add one more requirement:

• the Ruby 1.8.8 regexp must be compatible with 1.8.7

As far as I can tell 1.8.8 with the Oniguruma-Patch would be compatible. And it would also be a bridge to 1.9.2. I guess the problem is more that 1.9.2 would have to catch up with 1.8.8 in terms of Regexp. But that is less of a problem because 1.8.6 is still "tooo" stable ;). And I consider that a compliment as many enterprises are still using 1.8.6.

The lack of /g and /G is by design, 1.9.2 never catch up it.
Moreover Oniguruma patch's oniguruma is 2.5.8.

Yui Naruse wrote:

I think they are Rails users.
Their answer is showed by Rails 3.

Well, Enterprise users want to depend on Ruby not on a App that is build with Ruby. We do not build on Rails. We build on Ruby. But sure, Ruby on Rails is the "RedHat" of Ruby (but it should not be considered the only one).

So I am with Rick but I think it is not just the numbers it is also the timing cycle and it is Oniguruma.

I still can't understand why Oniguruma supports migration.

Actually I would also like to ask the question literally: Why does Matz say/think Ruby does not haveto/should not be consistent? http://bit.ly/Y1bQT - Can you point me to a current or old policy in respect to consistency of Ruby?

"Consistency is not a goal of Ruby" is still correct.
Anyway "1.8.8 should include Oniguruma" is not a consistency problem.

--
NARUSE, Yui [e-mail]

=end

[zdavatz (Zeno Davatz)]

=begin
Dear Yui-san

Thank you for your reply.

The year 2002 is the night before 1.8 is released, so we decided to
import Oniguruma in 1.9.

I still do not understand that decision. Based on what was that decision taken? Why did you decide against applying the Patch for 1.8 and instead introduced "half" of the Patch in Ruby 1.9? This truly does make Ruby inconsistent.

Yes, I know the Oniguruma gem. But I believe that gem should be applied as patch to the code. Now you have a gem, you have a patch and you have Ruby 1.9.2. Ruby should merge these features more aggressively.

"Consistency is not a goal of Ruby" is still correct.
Why is this not a goal? If you buy a car you want it to last as long as possible. If you use software I would expect the same. Consistency is key to nature and the environment.

For me it is important to understand why Ruby wants to be inconsistent.

When I boot into a new Kernel I expect it to boot. I do not expect a Kernel Panic.

The same goal would do Ruby well.

But maybe I will understand if you can explain me why Ruby does not want to be consistent.

Best
Zeno
=end

[matz (Yukihiro Matsumoto)]

=begin
Hi,

In message "Re: [ruby-core:34540] [Ruby 1.8-Feature#4239] Let's begin a talk for "1.8.8" -- How's needed for surviving 1.8?"
on Tue, 18 Jan 2011 00:49:40 +0900, Zeno Davatz [e-mail] writes:

|> The year 2002 is the night before 1.8 is released, so we decided to
|> import Oniguruma in 1.9.
|
|I still do not understand that decision. Based on what was that decision taken? Why did you decide against applying the Patch for 1.8 and instead introduced "half" of the Patch in Ruby 1.9? This truly does make Ruby inconsistent.

I am not sure if you understand what he said.

Oniguruma is the regular expression engine, which can be configured to
several flavor of regex dialects. So each application that embeds
Oniguruma could choose what feature set it uses. There's no "half"
introduction, just choice of dialect.

At the time Oniguruma merged into 1.9, we chose the feature set.
Even though you don't like the current feature set of 1.9 regular
expression, there's no chance to those missing feature merged in to
1.8. Period.

I repeat. There's no chance for Oniguruma merged into 1.8, since it
could cause incompatibility / regression that seriously hinders stable
nature of 1.8 series.

						matz.

=end

[zimbatm (zimba tm)]

=begin
2011/1/17 Zeno Davatz [e-mail]:

For me it is important to understand why Ruby wants to be inconsistent.

From the slides you link, it seems to me that the goal is to be useful
over consistency. It's not the same as willing to be inconsistent.

=end

[zdavatz (Zeno Davatz)]

=begin
Dear Matsumoto-san

Thank you for your reply.

I guess this boils down to the discussion of Micro-Kernel vs. Monolithic Kernel. I by far prefer the Monolithic Kernel, all in. I do not like modules in my Kernel. I always compile everything into my kernel. Obviously I expect the same of Ruby.

If you have time, could you please explain what you mean by 'it is not necessarily a goal of Ruby to be consistent'? Any links you can point out to cement that philosophy?

I somehow get the feeling that Ruby has a Top-Down Approach and not a Bottom-Up Approach. Features are designed from the visionary boiler-plate, Features do not develop like in Nature from the Bottom-Up. This I believe tends to break things as versus to integrate things.

I think it is better to integrate and extend.

I therefor vote for more inclusion of patches and therefore I vote explicitly for more consistency in Ruby.

I think this shift towards explicit consistency could start with Ruby 1.8.8.

I thank you for your time.

Best
Zeno
=end

[Cezary (Cezary Baginski)]

=begin
On Wed, Jan 19, 2011 at 12:41:45AM +0900, Zeno Davatz wrote:

Issue #4239 has been updated by Zeno Davatz.

If you have time, could you please explain what you mean by 'it is not necessarily a goal of Ruby to be consistent'? Any links you can point out to cement that philosophy?

This may sound like a cheesy reply from someone with much less
experience, but please bear with me.

http://www.artima.com/intv/ruby.html

From the article:

"Matz began work on Ruby back in 1993, because he wanted a language
that made him productive while being fun to use."

Quotes by Matz:

"I emphasize the feeling, in particular, how I feel using Ruby."

"I believe consistency and orthogonality are tools of design, not
the primary goal in design."

I can deeply relate to that, but only because Ruby seems like the
perfect language for me.

I honestly have the most fun when coding in Ruby. And I take that
"fun" part seriously ... If anyone knows a language more fun, let me
know and I'll switch in a heartbeat. Or if there is any other
language which has the same primary goal, I would love to compare.

Changing goals and visions to minimize project maintenance costs sound
like the opposite direction. That would be valuable, but I would
prefer that core developers spend more time on cool features, so they
can mature faster.

Personally, if the goal of keeping the language "nice" means other
sacrifices (like having huge costs in maintaining an old code base a
few years from now), I won't probably mind for a long time.

But then again, I have been only writing software for a little less
than 15 years, so maybe I will "grow up" and think different a few
years down the road. Or maybe not.

Regards,

Cezary

--
Cezary Baginski

Attachment: signature.asc
=end

[matz (Yukihiro Matsumoto)]

=begin
Hi,

In message "Re: [ruby-core:34557] [Ruby 1.8-Feature#4239] Let's begin a talk for "1.8.8" -- How's needed for surviving 1.8?"
on Wed, 19 Jan 2011 00:41:45 +0900, Zeno Davatz [e-mail] writes:

|I think it is better to integrate and extend.
|
|I therefor vote for more inclusion of patches and therefore I vote explicitly for more consistency in Ruby.

Merging patches designed by various people with various background
tends to reduce consistency, doesn't it? So I wonder why you can vote
more inclusion of patches and more consistency at the same time.

|I think this shift towards explicit consistency could start with Ruby 1.8.8.

I don't care about more consistency in 1.8; It's done. Stability
(i.e. no change) is the goal of the release. If you want more
consistency in the Ruby language, start discussion on 1.9.

						matz.

=end

[meta (mathew murphy)]

=begin
On Sun, Jan 16, 2011 at 12:26, Rick DeNatale [e-mail] wrote:

On Sun, Jan 16, 2011 at 12:19 PM, NARUSE, Yui [e-mail] wrote:

FYI, our semantic versioning spec for Ruby 1.x is for example Ruby
1.9.2-p136,
Major = 1.9
Minor = 2
Patch = 136

Which really is at odds with the way most packagers and users of
packages think of things.  I can't think of any other use of a 2 level
 major version 'number'.

Mac OS X.
X Window system.
GNU Emacs.
Java.
Microsoft Windows. (*)

Will that do?

mathew
[ (*) http://www.nirmaltv.com/2009/08/17/windows-os-version-numbers/ ]

URL:http://www.pobox.com/~meta/

=end

[naruse (Yui NARUSE)]

=begin
(2011/01/19 18:55), mathew wrote:

On Sun, Jan 16, 2011 at 12:26, Rick [e-mail] wrote:

On Sun, Jan 16, 2011 at 12:19 PM, NARUSE, [e-mail] wrote:

FYI, our semantic versioning spec for Ruby 1.x is for example Ruby
1.9.2-p136,
Major = 1.9
Minor = 2
Patch = 136

Which really is at odds with the way most packagers and users of
packages think of things. I can't think of any other use of a 2 level
major version 'number'.

Mac OS X.

3 level
http://support.apple.com/kb/DL1049

X Window system.
GNU Emacs.

Yes, 2 level.

Java.

It may be 4 level; or 2 level.
1.6.0_23 (a.k.a Version 6 Update 23)

Microsoft Windows. ()
[ () http://www.nirmaltv.com/2009/08/17/windows-os-version-numbers/ ]

It has service pack and many patch release (KBXXXXXX).
So it is 2+ level.
http://www.microsoft.com/downloads/en/details.aspx?FamilyId=66F1420C-DF2D-400B-A8A9-EF9061A9A3CA&displaylang=en

--
NARUSE, Yui [e-mail]

=end

[naruse (Yui NARUSE)]

=begin
(2011/01/18 0:49), Zeno Davatz wrote:

The year 2002 is the night before 1.8 is released, so we decided
to import Oniguruma in 1.9.

I still do not understand that decision. Based on what was that
decision taken? Why did you decide against applying the Patch for 1.8
and instead introduced "half" of the Patch in Ruby 1.9? This truly
does make Ruby inconsistent.

Why it makes Ruby inconsistent?

Yes, I know the Oniguruma gem. But I believe that gem should be
applied as patch to the code. Now you have a gem, you have a patch
and you have Ruby 1.9.2. Ruby should merge these features more
aggressively.

Why we should merge even if Oniguruma introduces incompatilibity?

"Consistency is not a goal of Ruby" is still correct.
Why is this not a goal? If you buy a car you want it to last as long
as possible. If you use software I would expect the same. Consistency
is key to nature and the environment.

For me it is important to understand why Ruby wants to be
inconsistent.

Consistency sometimes conflict with compatibility, speed, usability, and so on.

When I boot into a new Kernel I expect it to boot. I do not expect a
Kernel Panic.

The same goal would do Ruby well.

But maybe I will understand if you can explain me why Ruby does not
want to be consistent.

If you think consistency is like a Kernel Panic,
your "consistency" is different from what we think.

--
NARUSE, Yui [e-mail]

=end

[zdavatz (Zeno Davatz)]

=begin
Dear Matsumoto-san

Consistency should have been between Ruby 1.8 and 1.9. That is why I fight for a Ruby 1.8.8 because I want to bridge the inconsistent gap (the crevasse) between Ruby 1.8 and Ruby 1.9. Clearly you do not care about that consistency. Please tell me why you do not care about that consistency.

All of the Apps we wrote on Ruby 1.8. have to be rewritten for Ruby 1.9 - ALL of them! So obviously you only care about consistency within one major release.

I would prefer consistency between 1.8 and 1.9 and not within 1.8 and within 1.9. That is the problem.

Linus Torvalds shows how one can apply many patches from many different people and therefore keep up with consistency and with integrating patches at a fast pace. I think that should be the goal for Ruby as well.

I do not have a problem when features are phased out but switching to a new version should work seamlessly.
That is what I mean when I say booting into a new RC-Release of Kernel does not give me a kernel panic.

Linus hates it if people break existing features for the normal John-Doe user, but the kernel is still constantly being upgraded. That I totally agree with.

Dear Yui-san

When I boot into a new kernel then I do not get a Kernel-Panic in 97% of the cases. When I try to run my Ruby 1.8 Apps on Ruby 1.9 all of them have to be rewritten because so many things have fundamentally changed. Now that is inconsistent. Please watch how Linus Torvalds cares about consistency, then you know what I mean. Start booting into every RC Release Kernel. Always clone from the Linus git directory and you will get the feeling of what consistency is.

Dear Cezary

Yes, Ruby is "cool" but in my respect it cares to much about the coolness and the HIP-Style and not enough about consistency. The bigger your App grows the more important consistency is.

Best
Zeno
=end

[rosenfeld (Rodrigo Rosenfeld Rosas)]

=begin
On 10-01-2011 00:47, Charles Nutter wrote:

Issue #4239 has been updated by Charles Nutter.

1.8.7 is a good release. It should be the last 1.8.x release. There's no need to make a "better" 1.8.7 in 1.8.8, because 1.8.7 is just fine.

1.9.2 is a good release. Anyone who wants something better than 1.8.7 should just move to 1.9.2. There's no reason to make a transitional 1.8.8 because 1.9.2 is just fine.

JRuby 1.6 will support both 1.8.7 and 1.9.2 modes, meaning that the second most-commonly used Ruby implementation will support 1.9.2. Therefore, there's no reason to make a 1.8.8 since the above two statements apply to JRuby as well as C Ruby. It would also require us to maintain a third mode, since so many users will depend on 1.8.7 logic of today.

1.8.8 is not needed, and I don't see JRuby ever supporting it. I vote to eliminate ruby_1_8 branch, make 1.8.7 and ruby_1_8_7 the last 1.8.x version, and continue to maintain it as a maintenance branch only. 1.9.2 and successors are the future.

http://redmine.ruby-lang.org/issues/show/4239

---

http://redmine.ruby-lang.org

If 1.8.8 allowed the new syntax for Hashes ({a: 1, b: 2}), than I would
vote for 1.8.8.

This would allow library developers to adopt the more concise new Hash
syntax while still maintaining compatibility between 1.8 and 1.9...

Regards, Rodrigo

=end

[zimbatm (zimba tm)]

=begin
2011/1/20 Zeno Davatz [e-mail]:

When I boot into a new kernel then I do not get a Kernel-Panic in 97% of the cases. When I try to run my Ruby 1.8 Apps on Ruby 1.9 all of them have to be rewritten because so many things have fundamentally changed. Now that is inconsistent. Please watch how Linus Torvalds cares about consistency, then you know what I mean. Start booting into every RC Release Kernel. Always clone from the Linus git directory and you will get the feeling of what consistency is.

Do you have specific use-cases ? I have started a list of such things
if you want to contribute:
http://redmine.ruby-lang.org/wiki/ruby-19/MigrationIssuesFrom18

I understand your frustration, but it would be more helpful to discuss
specific points. These can then be used as an argument for 1.8.8 or,
what I think is more reasonable, a 1.9.3 release that make the
transition smoother.

=end

[matz (Yukihiro Matsumoto)]

=begin
Hi,

In message "Re: [ruby-core:34650] [Ruby 1.8-Feature#4239] Let's begin a talk for "1.8.8" -- How's needed for surviving 1.8?"
on Thu, 20 Jan 2011 18:30:29 +0900, Zeno Davatz [e-mail] writes:

|Consistency should have been between Ruby 1.8 and 1.9. That is why I fight for a Ruby 1.8.8 because I want to bridge the inconsistent gap (the crevasse) between Ruby 1.8 and Ruby 1.9. Clearly you do not care about that consistency. Please tell me why you do not care about that consistency.

Your wording is little bit different from us. We call your
"consistency" as "compatibility".

Compatibility is important, and we care for it. But we are imperfect,
thus we make mistakes in design of the language, that cannot be fixed
without breaking compatibility. So we have to break compatibility
time to time in the history of language development. Ruby 1.9 is one
of them.

|All of the Apps we wrote on Ruby 1.8. have to be rewritten for Ruby 1.9 - ALL of them! So obviously you only care about consistency within one major release.
|I would prefer consistency between 1.8 and 1.9 and not within 1.8 and within 1.9. That is the problem.

No matter how we design 1.8.8, you have to rewrite your program
anyway. Rewriting for 1.8.8 is no better than rewriting for 1.9.

						matz.

=end

[zdavatz (Zeno Davatz)]

• File test.rb test.rb added

=begin
Dear Matsumoto-san

Thank you for your reply.

I am imperfect too ;)

I think the way Ruby decides to apply patches is - how can I say - based on the "style" of the Micro-Kernel. Ruby should try harder to apply the patches faster and improve itself on those patches. Sorry but here I come again with the style of Linus how he applys patches basically by trying not to break old stuff with new changes but still constantly merging new changes into the mainline.

This may be off-topic, please point me to the relevant topic if so:

We are just working on our Ruby 1.9 application and we just found another consistency problem in Ruby 1.9. The way Hashes are iterated in Ruby 1.9.1 is different from the way Hashes are iterated in Ruby-1.9.2. Please do not do things like that. This stuff should just continue to work. This is my second example for consistency. Oniguruma was my first example (see the Michael Felling link).

Please see the attached Script that runs on Ruby 1.9.1 but does not run on Ruby 1.9.2 - again this breaks our software in Ruby 1.9.

Also, this change makes Ruby less flexible.

Thank you for your time.

Best
Zeno

PS: I by far prefer the word consistency to the word compatibility. The user of Ruby should experience a consistency when he upgrades to a newer Ruby Version. The user should not fall into the crevasse with every upgrade.
=end

[matz (Yukihiro Matsumoto)]

=begin
HI,

In message "Re: [ruby-core:34665] [Ruby 1.8-Feature#4239] Let's begin a talk for "1.8.8" -- How's needed for surviving 1.8?"
on Fri, 21 Jan 2011 00:53:13 +0900, Zeno Davatz [e-mail] writes:

|I think the way Ruby decides to apply patches is - how can I say - based on the "style" of the Micro-Kernel. Ruby should try harder to apply the patches faster and improve itself on those patches. Sorry but here I come again with the style of Linus how he applys patches basically by trying not to break old stuff with new changes but still constantly merging new changes into the mainline.

I have no experience on Micro-Kernel development, so that I cannot say
anything on that. But for me, your opinion - keeping and enhancing
consistency, and accepting more patches faster seem contradicting.
And as far as I hear from LKML subscribers, Linus breaks compatibility
often. Others often try to stop him.

|This may be off-topic, please point me to the relevant topic if so:

Open new issue on the redmine. In essence, it's the result of
accepting a patch in 1.9.2 to avoid a serious problem.

						matz.

=end

[zdavatz (Zeno Davatz)]

=begin
Dear Jonas

Thank you for the link. I just updated that link. Thank you for the hint. I still need to learn how to set anchors in that page.

I will also add some comments how the string Class completely changed in Ruby 1.9 from Ruby 1.8.

Best
Zeno
=end

[zdavatz (Zeno Davatz)]

=begin
Dear Matsumoto-san

Thank you for your reply.

I would not cherry-pick the features out of the patches (Oniguruma), I would apply them asap and then work up a release cycle where people know when they can commit new stuff (at rc1) and when they have to hold there horses (rc8) because a new stable release is about to be out. This cycle is of great importance. After all it is a great honor for Ruby if people write patches like the one of Oniguruma. That is one great patch upon which the improvements should be done. This is what I call chronologically logical. Evolution. Survival of the sickest.

I constantly watch Linus's communication and I can tell by my personal experience that rc-Kernel-Releases boot in 98% of the cases (git pull, make silentoldconfig, make, and then lilo with reboot and my machine is back up). Also debugging with "git bisect" is really easy, also for Non-Technical people. Aggressive merging in the right moment, slow merging in the right moment.

I will try to document all the breakages we encounter as Jonas recommended here:
http://redmine.ruby-lang.org/wiki/ruby-19/MigrationIssuesFrom18

Thank you for your time.

Best
Zeno
=end

[naruse (Yui NARUSE)]

=begin
(2011/01/21 1:14), Yukihiro Matsumoto wrote:

|This may be off-topic, please point me to the relevant topic if so:

Open new issue on the redmine. In essence, it's the result of
accepting a patch in 1.9.2 to avoid a serious problem.

It is intended changeon r26687.

--
NARUSE, Yui [e-mail]

=end

[matz (Yukihiro Matsumoto)]

=begin
Hi,

In message "Re: [ruby-core:34669] [Ruby 1.8-Feature#4239] Let's begin a talk for "1.8.8" -- How's needed for surviving 1.8?"
on Fri, 21 Jan 2011 02:30:57 +0900, Zeno Davatz [e-mail] writes:

|I would not cherry-pick the features out of the patches (Oniguruma), I would apply them asap and then work up a release cycle where people know when they can commit new stuff (at rc1) and when they have to hold there horses (rc8) because a new stable release is about to be out. This cycle is of great importance. After all it is a great honor for Ruby if people write patches like the one of Oniguruma. That is one great patch upon which the improvements should be done. This is what I call chronologically logical. Evolution. Survival of the sickest.

I am not sure how much you know about the development cycle of Ruby,
but 1.8 is not in the right cycle for fast merging. It's in the
stable stage. Why do you want to apply the patch (that introduces
incompatibility) to the stable release? That would cause more trouble
than benefit.

In contrast, trunk is moving, so if you propose something useful to
the trunk, it will be merged much easier.

|I will try to document all the breakages we encounter as Jonas recommended here:
|http://redmine.ruby-lang.org/wiki/ruby-19/MigrationIssuesFrom18

Thank you for your work.

						matz.

=end

[naruse (Yui NARUSE)]

=begin
(2011/01/21 0:53), Zeno Davatz wrote:

PS: I by far prefer the word consistency to the word compatibility.
The user of Ruby should experience a consistency when he upgrades to
a newer Ruby Version. The user should not fall into the crevasse with every upgrade.

Ah, I understand what you say.
The word "consistency" confused me...
If you used "compatibility", I could understand your intention much sooner.

--
NARUSE, Yui [e-mail]

=end

[zdavatz (Zeno Davatz)]

=begin
Dear Yui-san

I do not understand. So the Hash-Iteration will/should work again in r26687 as it used to work in Ruby 1.8.6 and in Ruby 1.9.1?

http://www.atdot.net/~ko1/w3ml/w3ml.cgi/ruby-cvs/msg/33902

So then my question is: When will we see that change applied, so the old habit of Ruby works again? Will that be in 1.9.3?

Thank you for your Feedback.

Best
Zeno
=end

[zdavatz (Zeno Davatz)]

=begin
Dear Matsumoto-san

I will try to be helpful with the Trunk development.

I still think it is very important that 1.8.8 is a bridge to Ruby 1.9.2. It should not be a dead-end road to stable heaven. It should be a bridge to Ruby 1.9. I think Ruby 2.0 can break everything but not 1.9. 1.9 should be the very stable version but should also cover everything that is in 1.8. But again, obviously I do not understand the release cycle of Ruby and I also think it is not that clear as to when one can expect things to be broken. When I read about Ruby 1.9.2 I get the impression is solves all my problems. Well if it breaks with old habits then it creates more problems. So something feels wrong for me.

Switching from Ruby 1.8.6 to Ruby 1.9.2 should be made hassle-free.

I think Ruby should in the future pay more attention to apply patches from the bottom up so that the User experiences more consistency when he switches to a new Ruby version.

It is essentially what I believe is the problem of the micro-kernel. It is chopped up in to many pieces. And it gets worse if new releases are designed from the top-down instead of from the bottom up (meaning evolution through patches is a good thing). That is what Linus does well. He breaks down new features, he does not break old ones because a current user should not have a bad experience when he upgrades. If you buy a new car and everything is different from the old model (in a sense that the concept is completely different) then you will feel betrayed as a customer. Great products come with great consistency. Great products make you feel the change in a positive way.

Please try not to break old habits, Methods and Concepts.

Best
Zeno
=end

[naruse (Yui NARUSE)]

=begin
2011/1/21 Zeno Davatz [e-mail]:

Issue #4239 has been updated by Zeno Davatz.

Dear Yui-san

I do not understand. So the Hash-Iteration will/should work again in r26687 as it used to work in Ruby 1.8.6 and in Ruby 1.9.1?

http://www.atdot.net/~ko1/w3ml/w3ml.cgi/ruby-cvs/msg/33902

So then my question is: When will we see that change applied, so the old habit of Ruby works again? Will that be in 1.9.3?

r26687 is the maker of 1.9.2's behavior.
This commit is because of the discussion held in
http://redmine.ruby-lang.org/issues/show/1535

--
NARUSE, Yui  [e-mail]

=end

[naruse (Yui NARUSE)]

=begin
2011/1/21 Zeno Davatz [e-mail]:

Issue #4239 has been updated by Zeno Davatz.
I still think it is very important that 1.8.8 is a bridge to Ruby 1.9.2. It should not be a dead-end road to stable heaven. It should be a bridge to Ruby 1.9. I think Ruby 2.0 can break everything but not 1.9. 1.9 should be the very stable version but should also cover everything that is in 1.8. But again, obviously I do not understand the release cycle of Ruby and I also think it is not that clear as to when one can expect things to be broken. When I read about Ruby 1.9.2 I get the impression is solves all my problems. Well if it breaks with old habits then it creates more problems. So something feels wrong for me.

You have some misunderstanding.
1.9 is what breaks 1.8 compatibility, and 2.0 is intended to be
compatible with 1.9.
You may understand by this explanation: 1.9.2 is 1.99.2 like Gnome's
versioning rule.

Switching from Ruby 1.8.6 to Ruby 1.9.2 should be made hassle-free.

So incompatibility between 1.8.x and 1.9.x is unavoidable and intended.
Though 2.0.x intends to have upper compatibility to 1.9.2.

I think Ruby should in the future pay more attention to apply patches from the bottom up so that the User experiences more consistency when he switches to a new Ruby version.

Our current goal is to migrate people to 1.9, not 1.8.8.
Your logic, 1.8.8 is helpful for migration to 1.9, is still unclear
and sticked on Oniguruma.
Such logic, backporting new feature to 1.8 helps migration, was also
done in 1.8.7.
You know the result.
You must show your logic is different from that of ours.

Anyway your this sentense is translated as, we should merge pathces
which introduces incompatibility
to keep compatibility to 1.9.
I think this is strange.

It is essentially what I believe is the problem of the micro-kernel. It is chopped up in to many pieces. And it gets worse if new releases are designed from the top-down instead of from the bottom up (meaning evolution through patches is a good thing). That is what Linus does well. He breaks down new features, he does not break old ones because a current user should not have a bad experience when he upgrades. If you buy a new car and everything is different from the old model (in a sense that the concept is completely different) then you will feel betrayed as a customer. Great products come with great consistency. Great products make you feel the change in a positive way.

Really?

Anyway, Language will change, must change.
You know many rotten languages because of old core spces.
Such languages will be replaced new one
Ruby wants to replace old Ruby by ourself.

Please try not to break old habits, Methods and Concepts.

We breaks old hapits to make better habits (in major bump).
(2.0 is not such major bump because 1.9 is such one, in current schedule)

--
NARUSE, Yui  [e-mail]

=end

[zdavatz (Zeno Davatz)]

=begin
Dear Yui-san

So can we expect a consistent behavior or a patch that fixes the Hash-Iteration for 1.9.2 as it worked for 1.8.6 and 1.9.1 but does not work for 1.9.2?

Also see: http://redmine.ruby-lang.org/wiki/ruby-19/%23Hash_Iteration

At the moment this behavior results in having to rewrite the pg gem and the dbi gem. This is not nice. This is very bad.

Best
Zeno
=end

[zdavatz (Zeno Davatz)]

=begin
Dear Yui-san

So what you are saying it that Ruby 1.8.6 is like Kernel 2.4 and Ruby 1.9 is like Kernel 2.6?

It still would be nice if you could use the old config as with the Kernel-config 2.4 (last release) in Kernel 2.6 (first release).

I think the general grandmother and normal user would have better understood if you would have made Ruby 1.9 consistent with Ruby 1.8 and make a totally new release with 2.0 that can break everything (well actually not to much). Big jumps should still be consistent.

I don't agree about old languages. Linux is so successful because it build on old Unix habits. Even Apple adopted those Unix habits - but Apple is also a good example taking advantage of old habits and then breaking everything in their favor. Apple is only consistent in their design innovations. I am not a Microsoft fan but Microsoft is consistent and that makes them strong.

Best
Zeno
=end

[zdavatz (Zeno Davatz)]

=begin
Dear Yui-san

I think you are replacing "old" Ruby with "new" Ruby to fast and with a Top-Down approach. The approach should be bottom up. "New" Ruby should build on "old" Ruby not replace it. That is what I mean with consistency.

New Ruby should assimilate to old, not old to new. Build on what is stable. Do not build on what is unstable.

Ruby 1.8.6 is stable. Enhance and extend those features. Do not just replace them.

Best
Zeno
=end

[naruse (Yui NARUSE)]

=begin
2011/1/21 Zeno Davatz [e-mail]:

So can we expect a consistent behavior or a patch that fixes the Hash-Iteration for 1.9.2 as it worked for 1.8.6 and 1.9.1 but does not work for 1.9.2?

Also see: http://redmine.ruby-lang.org/wiki/ruby-19/%23Hash_Iteration

At the moment this behavior results in having to rewrite the pg gem and the dbi gem. This is not nice. This is very bad.

If you can persuade us, it can be changed.
But did you read http://redmine.ruby-lang.org/issues/show/1535 ?
It says r26687 changes from "Exception may occur" to "shall occur".
You prefer unpredictable exception?

--
NARUSE, Yui  [e-mail]

=end

[zdavatz (Zeno Davatz)]

=begin
Dear Yui-san

Please correct me if I am wrong but in

http://redmine.ruby-lang.org/issues/show/1535

Yusuke Endoh says that

But I agree with Run Paint Run Run's opinion. It may lead to difficult bug to indeterminately fail to add a new key.

but that is not at all proven by Run Paint Run Run case. Then Matz goes ahead and flags that unproven claim as ok and Ruby 1.9.2 is pachted and more inconsistency is created, based on some bug that "!may!" happen in the future.

Our case of http://redmine.ruby-lang.org/wiki/ruby-19/%23Hash_Iteration is a very simple practical Live-Software Hash iteration Case that works in Ruby 1.8.6, 1.9.1 and then breaks in 1.9.2 because of some theoretical "may".

In my opinion this is not practical thinking it is theoretical thinking based on ifs and whens.

I would recommend you should at least have one practical Use-Case (running live Software or gem) that shows that his/her application(s) becomes broken before you do changes based on some "maybe".

And the moment your "maybes" break existing software and that is wrong. That is not good. That is not consistent.

Best
Zeno
=end

[naruse (Yui NARUSE)]

=begin
2011/1/21 Zeno Davatz [e-mail]:

I think you are replacing "old" Ruby with "new" Ruby to fast and with a Top-Down approach.
The approach should be bottom up. "New" Ruby should build on "old" Ruby not replace it.
That is what I mean with consistency

Yeah, I understand what you are saying now.
And we say no; we know compatibility is important but believe
sometimes other things more important.
Such decision is design issue, and they are decided by Matz (or the
maintainer of the library).
We belive such design issue is not suitable for the method decision by majority.

Anyway of course requests are bottom up.
But as Matz design the feature, a requester must provide the material
for judging.
People seems not to understand this and requests are often suspended.

New Ruby should assimilate to old, not old to new. Build on what is stable. Do not build on what is unstable.

NO again, and it's too late for 1.9.
1.9 has many fundamental imcompatibility.

2.0 is expected to be mostly compatible 1.9, so you can object when
2.0 become incompatible.

Ruby 1.8.6 is stable. Enhance and extend those features. Do not just replace them.

Yeah, so Engine Yard maintain 1.8.6.
Enterprise users can use 1.8.6 as long as EY supports it.

--
NARUSE, Yui  [e-mail]

=end

[zdavatz (Zeno Davatz)]

=begin
Dear Yui-san

This is another thing I learned from Linus Torvalds: Think practical don't think theoretical.

Think of the Users that run Ruby and let them tell you if something breaks and then fix based on the practical Use-Case. I prefer to see that something happens instead being afraid that it may happen. Why? Because it may not happen or it may happen differently then you thought.

I prefer real-life proof.

Best
Zeno
=end

[naruse (Yui NARUSE)]

=begin
2011/1/21 Zeno Davatz [e-mail]:

Please correct me if I am wrong but in

http://redmine.ruby-lang.org/issues/show/1535

Yusuke Endoh says that

 But I agree with Run Paint Run Run's opinion.  It may lead to difficult bug to indeterminately fail to add a new key.

but that is not at all proven by Run Paint Run Run case. Then Matz goes ahead and flags that unproven claim as ok and Ruby 1.9.2 is pachted and more inconsistency is created, based on some bug that "!may!" happen in the future.

Our case of http://redmine.ruby-lang.org/wiki/ruby-19/%23Hash_Iteration is a very simple practical Live-Software Hash iteration Case that works in Ruby 1.8.6, 1.9.1 and then breaks in 1.9.2 because of some theoretical "may".

Not theoretical "may", the example in the first post shows it.

In my opinion this is not practical thinking it is theoretical thinking based on ifs and whens.

I would recommend you should at least have one practical Use-Case (running live Software or gem) that shows that his/her application(s) becomes broken before you do changes based on some "maybe".

And the moment your "maybes" break existing software and that is wrong. That is not good. That is not consistent.

Of course true theoretical "may" like collision of SHA1 (assume SHA1
is safe) is nonsense.
But this is enough happened (because he hit this).
In such case, this causes unpredictable bug
and random bugs are so hard to debug that it should be fixed.

--
NARUSE, Yui  [e-mail]

=end

[spatulasnout (B Kelly)]

=begin
Hi,

Zeno Davatz wrote:

This is another thing I learned from Linus Torvalds: Think practical
don't think theoretical.

Think of the Users that run Ruby and let them tell you if something
breaks and then fix based on the practical Use-Case. I prefer to see
that something happens instead being afraid that it may happen. Why?
Because it may not happen or it may happen differently then you
thought.

I prefer real-life proof.

I'm inclined to doubt Linus takes such a wait-and-see approach
with regard to potential kernel panics, or potential rootkit
exploit vectors.

I'd be looking to migrate my servers to a different OS if he did.

Similarly, I would be vastly concerned, disappointed, disheartened,
and frankly incredulous were the ruby-core developers to allow a
potential (not to mention demonstrated) source of instability such
as this Hash#merge! inconsistency to remain lurking in the Ruby
language unaddressed, once it had been discovered.

As someone wrote on a different mailing list just a couple days
ago:

 Humans look at probability and say "this happens less
 than once is a <BIG NUMBER>" and perceive this to mean
 "it never happens".  The point here is that things
 that a well loaded, always running process will do so
 much work that these things that almost never happen
 can actually occur regularly.

 It is the classic case of it you are statistically
 unlikely to ever win the lottery, even if you play at
 every opportunity.  And yet - there are lottery
 winners every couple of weeks.  People forget this
 counter intuitive situation and would write off a bug
 that will bite them on the basis that it is "extremely
 unlikely", when you're running your code often enough
 "practically impossible" can become a yearly,
 quarterly, monthly, weekly or daily problem.

         (Brian Barrett, SDL mailing list, 17-Jan-2011)

In short: You may never experience this Hash#Merge issue personally.
But one of your users will.

Finally, as someone quite rightly chastised my 17-year-old punk ass
twenty-two years ago:

A Toast:
Here's to all Empirical Programmers; may their work never
inhabit my disks.

Cheers,

Bill

=end

[zdavatz (Zeno Davatz)]

=begin
Dear Yui-san

Sorry I do not agree. We do not use Hash-Merge we use the normal HashIteration and that is broken now as well because of some random If-Case that is not proven. Sorry, I see no proof, I see only a claim. To change a feature and breaks basic compatibility because of one thing that may or may-not happen is not user-friendly.

Also: Where is you practical proof?

Dear Bill

Do you use Hash-Interations? I don't think so. It does not seems so or you just started using them in Ruby 1.9.2. We use them at least since Ruby 1.8.6.

Also: You obviously do not boot into RC-Release kernels and you also do not follow the postings of Linus. Baiscially you just profit from both but you do not realize that you profit from true consistency.

Also I do not play the Lottery. I prefer consistency.

Best
Zeno
=end

[zdavatz (Zeno Davatz)]

=begin
Dear Bill

Do you make a living of playing the lottery? I do not. I make a living from running ruby Software on Linux servers and hopefully soon on Windows as well. Enterprise users care about consistency. Actually Desktop-Users care about consistency as well.

Best
Zeno
=end

[naruse (Yui NARUSE)]

=begin
2011/1/21 Zeno Davatz [e-mail]:

Sorry I do not agree. We do not use Hash-Merge we use the normal HashIteration at that is broken now as well because of some random If-Case that is not proven. Sorry, I see no proof, I see only a claim. To change a feature and break basic compatibility because of one thing that may or may-not happen is not user-friendly.

Also: Where is you practical proof?

Did you run following code?

hash = {1 => 2, 3 => 4, 5 => 6}
big_hash = {}
64.times { |k| big_hash[k.to_s] = k }
hash.each { hash.merge!(big_hash) }

I think he find this by accident (maybe when digging iterations for rubyspec).

--
NARUSE, Yui  [e-mail]

=end

[naruse (Yui NARUSE)]

=begin
2011/1/21 Bill Kelly [e-mail]:

Similarly, I would be vastly concerned, disappointed, disheartened,
and frankly incredulous were the ruby-core developers to allow a
potential (not to mention demonstrated) source of instability such
as this Hash#merge! inconsistency to remain lurking in the Ruby
language unaddressed, once it had been discovered.

Linux addresses all such potential instability?
That's great!

--
NARUSE, Yui  [e-mail]

=end

[spatulasnout (B Kelly)]

=begin
Zeno,

Zeno Davatz wrote:

Do you use Hash-Interations? I don't think so. It does not
seems so or you just started using them in Ruby 1.9.2. We
use them at least since Ruby 1.8.6.

Since you ask: I've been using ruby on a roughly daily basis
since 1999.

Here is code from a current project where I take steps to
avoid a Hash iterator due to the potential for the Hash to
be modified during iteration:

def close_all_catalogs
# NOTE: sv.close_all_catalogs may switch fibers,
# and we don't want to be iterating on @servers itself during that
# time, else another method like add_server would get
# "RuntimeError - can't add a new key into hash during iteration"
svs = @servers.values
svs.each do |sv|
sv.close_all_catalogs
end
end

Also I do not play the Lottery. I prefer consistency.

You are playing the Lottery in ruby 1.8 if you are modifying
a hash during iteration.

$ ruby186 -v -e "h = {:a=>123,:b=>456,:c=>789}; h.each_key {|k| p k; 3.times {|i| h[i.to_s]=i}}"
ruby 1.8.6 (2009-06-08 patchlevel 369) [i386-mswin32_71]
:a
:b
:c
"0"
"1"
"2"

$ ruby186 -v -e "h = {:a=>123,:b=>456,:c=>789}; h.each_key {|k| p k; 10000.times {|i| h[i.to_s]=i}}"
ruby 1.8.6 (2009-06-08 patchlevel 369) [i386-mswin32_71]
:a
-e:1:in `each_key': hash modified during iteration (RuntimeError)
from -e:1

You should not be adding new keys to a Hash during
iteration, if you claim to value "consistency".

Regards,

Bill

=end

[spatulasnout (B Kelly)]

=begin
Greetings,

NARUSE, Yui wrote:

2011/1/21 Bill Kelly [e-mail]:

Similarly, I would be vastly concerned, disappointed, disheartened,
and frankly incredulous were the ruby-core developers to allow a
potential (not to mention demonstrated) source of instability such
as this Hash#merge! inconsistency to remain lurking in the Ruby
language unaddressed, once it had been discovered.

Linux addresses all such potential instability?
That's great!

I wonder if I may have been misunderstood. What I was trying to say
was:

I wholeheartedly applaud the following decision by ruby-core:

"It may lead to difficult bug to indeterminately fail to add a new
key. So, I propose to permit only updating value of existing key, and
to always prohibit adding a new key: [...] This does not cause
compatibility problem because this just raises exception that has
already been occurred indeterminately."

I believe this is the correct decision, and I would have been
disappointed if instead the indeterminate behavior were allowed to
remain.

Regards,

Bill

=end

[zdavatz (Zeno Davatz)]

=begin
Dear Bill

In my opinion you prove to like theory over practice. Ok, the Hash-Iteration happens with big Hashes, surely so, but please show me one practical Use-case where i.e. the Users of Ruby 1.8.6 like Engine Yard complain that it is a problem for them? This whole thing is based on to many ifs and whens and one maybe! You still have not shown me a real-life practical use-case. Also in your first code example where is your Hash? I get No2 and No3, No3 has a long Hash and that creates an error. But I do not know of a practical use-case for that.

In contrast I have a very simple Use-Case for you. Ruby 1.9.2 breaks the dbi gem because the dbi-gem uses simple normal HashIteration to load Data from our Postgresql 8.4 database into the Cache in our application. We have millions of Views per Year (peak time can be 2000 - 3000 rps) and not a single complaint with Ruby 1.8.6. But if we want to switch to Ruby 1.9.2 then it just stops working because the dbi-gem does not work anymore and that thing has a huge tail!

And this is what Ruby should care about. This is what Linux cares about but I think you do not really notice that.

So this my practical proof for you.

So ask yourself: What is more important: The normal practical use-case or the scientific one? Of course it is the normal practical use case.

Ruby should not care about the long Hash-Iteration-Problem so long as there is no practical use-case. Engine Yard and all the other Ruby 1.8.6 users seems to work perfectly fine with normal HashIteration.

Best
Zeno
=end

[luislavena (Luis Lavena)]

=begin
On Fri, Jan 21, 2011 at 9:57 AM, Zeno Davatz [e-mail] wrote:

In contrast I have a very simple Use-Case for you. Ruby 1.9.2 breaks the dbi gem because the dbi-gem uses simple normal HashIteration to load Data from our Postgresql 8.4 database into the Cache in our application. We have millions of Views per Year (peak time can be 2000 - 3000 rps) and not a single complaint with Ruby 1.8.6. But if we want to switch to Ruby 1.9.2 then it just stops working because the dbi-gem does not work anymore and that thing has a huge tail!

And this is what Ruby should care about. This is what Linux cares about but I think you do not really notice that.

Zeno, in case you miss the poiint of dunno how many times Matz has said:

Compatibility break between 1.8.x and 1.9.x WAS PLANNED EXPECTED.

There is a new syntax, a new VM and lot of new features around Unicode
that break was the only way to achieve them.

Yes, a bummer, but no upgrade is free. that is why you have Unit Tests
(TDD) to drive your application and know in advance that these things
will break and where, right?

If you asked this 2 years ago, when 1.9.1 was under works, I think
will be acceptable, but 1.9.2 is out now, so API and behaviors of it
needs to remain compatible with previous patchlevels of it

So, bring your points to 1.9.3 (trunk), but consider that trunk needs
to remain compatible up to certain point with 1.9.2

I think you're completely missing that point. Is not about theory
versus practice or how many rps your application handles. Is about
every component that needs to be compatible with the version of Ruby
you're planning on use. That is what tests are good for.

It is OK break compatibility if the obtained benefits are greater.
Look at Python history if you want.

And please, stop "Linus this, Linus that" because Ruby != Linux
kernel. Different models, different needs and a whole different world.

Luis Lavena
AREA 17

Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry

=end

[zdavatz (Zeno Davatz)]

=begin
Dear Luis

Long-time no see! Thank you for your Feedback.

Please bring some practical examples to the table. Do you even use the dbi-gem?

Linux is consistent and compatible in many ways. I express my opinion about that. You are a windows user as I understand. You are used to consistency by birth ;) - I think Ruby can learn from Linux. Yes I do. Linux has a very transparent update-process, a very practical one. Booting into new RC-Releases just works.

So please teach me one thing: Ruby-1.8.6 is stable. Ruby 1.9 is a huge break with Ruby 1.9. Ruby 2.0 should be a better Ruby 1.9.

What will Ruby 2.1 be? I can not detect a practical release cycle logic I can not detect any bridges between the versions. All I can see are a lot of new, "cool" features. But I am willing to learn. So how is it? How does it work?

With Linux I can clearly detect the release cycles. It is a RC-Release every other week counting from rc1 (ambitious and crazy new stuff) to rc8 (smoothening out everything for the next stable release). Linus will never accept crazy stuff in RC8, he will in RC1. But still the PC will boot up again in the new stable release.

Simple, effective, consistent practical. I guess that is the reason why you work on Windows in the first place.

Best
Zeno
=end

[austin (Austin Ziegler)]

=begin
You're looking at 1.9.2 as if the version were major.minor.patch. It isn't, as has been noted in the past.

Ruby's current versioning is closer to paradigm.major.minor-ppatch.

-a « from my iPhone

=end

[zdavatz (Zeno Davatz)]

=begin
Dear Austin

Thank you for your input.

Can you be a bit more specific please or can you point me to a thread I should read. Ruby versioning seems one big book of secrets it seems.

Paradigm: does that stand for Top-Down-Design? Also what is the difference between .patch an -ppatch?

Best
Zeno
=end

[mwaechter (Matthias Wächter)]

=begin
Hi Zeno,

On 21.01.2011 13:57, Zeno Davatz wrote:

In contrast I have a very simple Use-Case for you. Ruby
1.9.2 breaks the dbi gem because the dbi-gem uses simple
normal HashIteration to load Data from our Postgresql 8.4
database into the Cache in our application. We have millions
of Views per Year (peak time can be 2000 - 3000 rps) and not
a single complaint with Ruby 1.8.6. But if we want to switch
to Ruby 1.9.2 then it just stops working because the dbi-gem
does not work anymore and that thing has a huge tail!

Why don’t you just fix ruby-dbi, upgrade ruby to 1.9.2 and continue life? ruby-dbi is broken misusing an inconsistency of 1.8.6’s hash iteration. This
was fixed in 1.9.2 by disallowing this consistency hole, so my advise is to update your libraries.

An analogy: Say, you have a housekeeper and an alarm system. The alarm system is good in detecting that someone has stolen something, but it is not
yet good in the main discipline of the newly adverted system, detecting unlocked doors. Some day, you replace it by the new version. Soon, you get a
daily alarm any time the housekeeper leaves. It appears that not only she forgets to lock the door when leaving, but she always did so for the last
years. Now you come and blame the new alarm system for detecting this error, as there was never a single theft when the old alarm system was in place,
and you go on with the old alarm system to get rid of the false alarm.

So, again: Fix ruby-dbi. It’s not ruby’s (or Matz’s fault) that ruby-dbi is not actively maintained anymore. Furthermore, ruby-dbi is not that big
kind of a library. There are two occurrences of each_key in the code, and one of them (ColumnInfo#initialize in columninfo.rb) is broken in this
regard but easy to fix.

Check that change (without testing):

    def initialize(hash=nil)

! hash ||= Hash.new
@hash = hash.dup rescue nil
@hash ||= Hash.new

        # coerce all strings to symbols

! hash.each_key do |x|
if x.kind_of? String
sym = x.to_sym
if @hash.has_key? sym
raise ::TypeError,
"#{self.class.name} may construct from a hash keyed with strings or symbols, but not both"
end
@hash[sym] = @hash[x]
@hash.delete(x)
end
end

        super(@hash)
    end

Cheers,
– Matthias

=end

[zdavatz (Zeno Davatz)]

=begin
Dear Matsumoto-san

Well just FYI but the pg gem also does not work with Ruby 1.9.2 - it used to work with Ruby 1.8.6 and Ruby 1.9.1 - We just tested it with our Ruby 1.9.1 application.

So we truly have a history of inconsistency that will make a lot of Postgresql-Users not want to switch to Ruby 1.9.2 because some many things are different (dbi, pg, Regex). As far as I can tell the pg problem is more complex then the dbi problem. So who has knowledge about the pg Problem with Ruby 1.9.2?

And if you have a bit of a complex system you surely used Oniguruma in Ruby 1.8.6.

So there we go. I do not know but is this a q.e.d for inconsistency? This is not healthy for your grandmother.

Now who has to adapt? pg gem to Ruby or Ruby to pg?

Again I would say that Ruby 1.8.8 should somehow bridge this gap as I guess Ruby 1.9.2 does not want to adapt.

Best
Zeno
=end

[luislavena (Luis Lavena)]

=begin
On Fri, Jan 21, 2011 at 12:49 PM, Zeno Davatz [e-mail] wrote:

Well just FYI but the pg gem also does not work with Ruby 1.9.2 - it used to work with Ruby 1.8.6 and Ruby 1.9.1 - We just tested it with our Ruby 1.9.1 application.

Once again, you're wrong.

'pg' gem works with Ruby 1.9.2. Author has been very supportive about that.

You're talking about old gems.
https://rubygems.org/gems/ruby-pg

2008! Last release of that gem!

Please be accurate with your statements.

In your perseverance you're proving yourself more as troll than a Ruby
developer. In your continuos call of consistency you clearly ignores
the point and the value of answers already provided by all, including
Matz.

Sadly this is the first thread of Ruby-Core that earned the use of
mute of Gmail.

Luis Lavena
AREA 17

Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry

=end

[matz (Yukihiro Matsumoto)]

=begin
Hi,

In message "Re: [ruby-core:34747] [Ruby 1.8-Feature#4239] Let's begin a talk for "1.8.8" -- How's needed for surviving 1.8?"
on Sat, 22 Jan 2011 00:49:10 +0900, Zeno Davatz [e-mail] writes:

|And if you have a bit of a complex system you surely used Oniguruma in Ruby 1.8.6.

I have never seen "a complex system that use Oniguruma" instead of 1.8
regex. Probably you are in the 1.8 Oniguruma cluster that we don't
belong.

|Now who has to adapt? pg gem to Ruby or Ruby to pg?

pg gem to 1.9.

|Again I would say that Ruby 1.8.8 should somehow bridge this gap as I guess Ruby 1.9.2 does not want to adapt.

I saw you said 1.8.8 should bridge the gap between 1.8.7 and 1.9.2,
but I am sorry that I don't understand your logic. I don't think
applying patches or making incompatible changes to 1.8.7 help bridge
the gap between 1.8 and 1.9.

						matz.

=end

[zdavatz (Zeno Davatz)]

=begin
Dear Matthias

I do not want to give the fault to anybody, want to track down why our Application simply does not start-up on Ruby 1.9.2 as it does on Ruby 1.8.6.

As far as I can summarize this:

1. dbi has a Hash-Iteration that can be fixed easily as Chuck pointed out here:

• h.each_key do |k|

• h.keys.each do |k|

thank you Chuck what a beautiful one line change. We needed several lines to change that. You are smarter!

2. pg does not work with Ruby 1.9.2 because of some PGconn error that we could not track down yet even though we tried all afternoon. PGconn is called by dbd-pg (0.3.9) but there we need to continue later: http://url.ba/hgwg

3. Oniguruma - Regexp. Has been discussed enough by Michael Fellinger and myself.

So it actually was a fruitful day and we need to continue with pg for Ruby 1.9.2 asap. So please let me know if you have any hints.

Best
Zeno
=end

[zdavatz (Zeno Davatz)]

=begin
Dear Luis

Do you even run an application that uses the pg gem? No I am not talking about ruby-pg 0.7.9.2008.01.28 - I am talking of the pg gem Version 0.10.1 it does not work for us on Ruby 1.9.2. But it does work on Ruby 1.8.6 and it does work on Ruby 1.9.1 so I think this is strange.

But obviously pg has to adapt to Ruby 1.9.2. Why, I do not yet understand.

Best
Zeno
=end

[zdavatz (Zeno Davatz)]

=begin
Dear Matsumoto-san

I guess I learned a lot of Ruby-Politics today. I would summarize like this:

1. You prefer the Top-Down approach. Inventing new features on the sketch board not integrating them based on patches. I take Oniguruma as an example.

2. Your versioning is a about as opposite as it could be to the Kernel versioning. Your release cycle is as Austin says: paradigm.major.minor-ppatch. I do not understand that yet.

3. New Features are designed, gems have to adapt, even if gems worked across major versions. Example: pg (0.10.1) gem on Ruby 1.8.6, Ruby 1.9.1 is ok, but on Ruby 1.9.2 it is broken according to our App.

Best
Zeno
=end

[austin (Austin Ziegler)]

=begin
On Fri, Jan 21, 2011 at 9:42 AM, Zeno Davatz [e-mail] wrote:

Issue #4239 has been updated by Zeno Davatz.
Can you be a bit more specific please or can you point me to a thread I should read. Ruby versioning seems one big book of secrets it seems.

This was stated earlier in this thread ([ruby-core:34527]). In the
entire time that I've been using Ruby where 1.9 has been discussed,
it's always been discussed as "making incompatible changes so that the
transition to 2.0 is cleaner."

Paradigm: does that stand for Top-Down-Design? Also what is the difference between .patch an -ppatch?

It's a word that I'm using in this sense to mean "larger than a Major
version". The pattern is:

1.9.2-p302

It's Major 1.9 (or Paradigm 1, Major 9), minor 2, patch 302. I should
have done my example as:

P'.'M'.'m'-p'p

to make it clear that the first p in ppatch was a literal.

I would suggest that you stop thinking that 1.9 is a minor version of
Ruby v1. It's not and never has been. It's a new major version with
planned incompatibilities. There are some unplanned incompatibilities,
but those are fixing real errors. This is like suggesting that Mac OS
X 10.5 was a minor version; it was not, in fact. Other versions are
even more inscrutable (HP-UX, anyone?)

There may be a case for Ruby 1.8.8 (I'm not convinced), but increased
compatibility between 1.8 and 1.9 is not such a case. Arguing that
1.9.2 is fundamentally broken because it provides a guarantee of
failure for certain cases that are statistically unlikely (but
virtually certain to happen in large enough cases) won't get you very
far.

In sum: 1.9 is a major version release of Ruby with promised
incompatibilities and it has a few that weren't promised but turn out
to be good ideas in practice despite some hardships that folks are
facing because of unsupported third-party libraries.

-a

Austin Ziegler • [e-mail] • [e-mail]
http://www.halostatue.ca/ • http://twitter.com/halostatue

=end

[zdavatz (Zeno Davatz)]

=begin
Dear Austin

Thank you for your Input. I will hardlink it and try to understand better.

In the meantime for the Postgresql Users out there that want their Apps to work on Linux and Windows my Observations:

pg 0.10.1 does not build on Ruby 1.9.1 on Windows. It does build on Linux with Ruby 1.9.1.

pg gem 0.10.1 does work on Linux with Ruby 1.9.1 and Ruby 1.8.6 but does not work with Linux with Ruby 1.9.2

Best
Zeno
=end

[meta (mathew murphy)]

=begin
On Thu, Jan 20, 2011 at 03:30, Zeno Davatz [e-mail] wrote:

Consistency should have been between Ruby 1.8 and 1.9. That is why I
fight for a Ruby 1.8.8 because I want to bridge the inconsistent gap (the
crevasse) between Ruby 1.8 and Ruby 1.9.

The thing you seem to be missing is that consistency should only go one way.

Ideally, any 1.8.x Ruby program would work in Ruby 1.9.x.

However, it is absolutely not the case that any 1.9.x program should
work in 1.8.x. Otherwise 1.9 would just be another 1.8. It was never
intended to be that; it was intended to be a superset of 1.8, with
major new functionality.

If you want any of the new functionality in Ruby 1.9, move to 1.9.

If you give examples of things that work in vanilla 1.8.x and break in
1.9.x, I think people will be sympathetic and try to find fixes.

If you demand the reverse, that new features be added to 1.8.x, I
think you'll continue to be on your own.

Moving new functionality from 1.9 to 1.8.8 would be absolutely the
wrong thing for Matz to do, precisely because it would break existing
1.8 programs, the way your programs have apparently been broken when
you tried to move them to 1.9.

But having said that...

All of the Apps we wrote on Ruby 1.8. have to be rewritten for Ruby 1.9

• ALL of them! So obviously you only care about consistency within one
  major release.

...I've got to say, if you've really had to rewrite everything to get
it to run on 1.9, you must be doing something seriously wrong. The
only problems I've hit have been caused by file encodings, and most of
them were fixed by declaring utf-8 at the top of the code.

mathew

URL:http://www.pobox.com/~meta/

=end

[meta (mathew murphy)]

=begin
On Fri, Jan 21, 2011 at 10:11, Zeno Davatz [e-mail] wrote:

2. pg does not work with Ruby 1.9.2 because of some PGconn error that
   we could not track down yet even though we tried all afternoon.
   PGconn is called by dbd-pg (0.3.9) but there we need to continue
   later: http://url.ba/hgwg

I would suggest that you
(a) start a new ticket for this apparent pg gem problem, and
(b) dump the actual SQL which is being sent to PostgreSQL, so the rest
of us can attempt to reproduce the problem.

The definition of the relevant table(s) would also be helpful.

My suspicion from the error message is that it's not actually pg or
Ruby at fault, but something else is trying to create an index which
already exists--either because it's failing to detect that the index
exists, or because it's creating a temporary index and then failing to
remove it.

If you can get me some actual SQL which fails when passed to pg in
1.9.2 but works when passed to pg in 1.9.1, I'll be glad to try and
reproduce the problem.

mathew

=end

[headius (Charles Nutter)]

=begin
On Fri, Jan 21, 2011 at 2:46 AM, Zeno Davatz [e-mail] wrote:

Issue #4239 has been updated by Zeno Davatz.

Dear Yui-san

So can we expect a consistent behavior or a patch that fixes the Hash-Iteration for 1.9.2 as it worked for 1.8.6 and 1.9.1 but does not work for 1.9.2?

Also see: http://redmine.ruby-lang.org/wiki/ruby-19/%23Hash_Iteration

At the moment this behavior results in having to rewrite the pg gem and the dbi gem. This is not nice. This is very bad.

JRuby 1.8 and 1.9 modes (equivalent to 1.8.7 and 1.9.2) both reject
this code as well. It's difficult to maintain hash consistency during
direct iteration if you allow mutation. In JRuby's case, this
simplifies the logic, prevents insertion from causing iteration to run
forever, and makes concurrent iteration by multiple threads safe
(since they can't directly mutate the hash during iteration).

• Charlie

=end

[headius (Charles Nutter)]

=begin
On Fri, Jan 21, 2011 at 12:52 PM, Charles Oliver Nutter
[e-mail] wrote:

JRuby 1.8 and 1.9 modes (equivalent to 1.8.7 and 1.9.2) both reject
this code as well. It's difficult to maintain hash consistency during
direct iteration if you allow mutation. In JRuby's case, this
simplifies the logic, prevents insertion from causing iteration to run
forever, and makes concurrent iteration by multiple threads safe
(since they can't directly mutate the hash during iteration).

I should also add that mutation-during-iteration has always been a
grey area for me, even when libraries do specify how it should behave.
Something about mutating the collection I'm walking while I'm walking
it makes me nervous.

• Charlie

=end

[zdavatz (Zeno Davatz)]

=begin
Dear Charlie

May I ask you on what OS your system runs on. Do you use the pg gem? If so what version? We do not use SQL the normal way. We store marshalled data in Postgresql and then manage the memory with our own Software ODBA. ODBA unmarshalls the data via dbi and displays it in the browser. At start-up of our application all the data goes into the memory. The system starts up perfectly clean with Ruby 1.9.1. It does not with Ruby 1.9.2. So something in Ruby 1.9.2 breaks the pg gem.

The memory is being managed by:
http://scm.ywesee.com/?p=odba/.git;a=summary

You can find all our software here: http://scm.ywesee.com

Since we found this http://just.do/2007/07/18/heap-fragmentation-in-a-long-running-ruby-process/

we are stable with mod_ruby with a lot of rps per second. I love mod_ruby! It needs to be ported to Windows asap.

Plus the problem of today you can find here: http://dev.ywesee.com/wiki.php/Masa/20110121-setup-ramaze

This is a pg problem with Ruby 1.9.2 you can trust me about that. We are on Linux Gentoo.

Best
Zeno
=end

[zdavatz (Zeno Davatz)]

=begin
Dear Mathew

It seems that what you say, I say as well. I never said that if you write something for Ruby 1.9 it should work for Ruby 1.8 as well. I said the contrary: If you write something for Ruby 1.8 it should work on Ruby 1.9 as well.

I exaggerated when I said we have to rewrite "all" our Libraries. But we have to rewrite a lot more then I expected. And ideally I would expect the same of Ruby as I expect of the Kernel. Upwards compatibility of old features. That should always work.

Oniguruma is a nice example that should have been merged into mainline ages ago. But instead just some feature where cherry-picked. The core team still has not given me a reason for that decision. I guess it was taken "out of fear not to introduce to many new things to fast". But the Oniguruma-Patch should have been merged a lot more aggressive right from the beginning in 2002.

What I am saying is "bridge". Think of a bridge as 1.8.8 to version 1.9.2. Maybe 1.8.9 could be another bridge to 1.9.3.

Your idealism of compatibility in one direction suits me just fine. Compatibility combined with consistency. But the idea of being compatible just with in one paradigm as within 1.9 or within 1.8 that feels wrong to my mindset. But that is the way Matsumoto-san wants it.

Best
Zeno
=end

[meta (mathew murphy)]

=begin
On Fri, Jan 21, 2011 at 13:55, Zeno Davatz [e-mail] wrote:

It seems that what you say, I say as well. I never said that if you write
something for Ruby 1.9 it should work for Ruby 1.8 as well. I said the
contrary: If you write something for Ruby 1.8 it should work on Ruby
1.9 as well.

Well, I said ideally. That word is important. One of the key goals
of 1.9 was to make certain necessary changes that do, unfortunately,
break compatibility with code written for 1.8. The addition of Unicode
support and multiple character encodings was one of the big ones.

Oniguruma is a nice example that should have been merged into
mainline ages ago. But instead just some feature where cherry-picked.

The reality is that your favorite features aren't necessarily going to
make it into the core language. Mine aren't either. I'm sure there are
people who would have liked full Perl regexp support too.

If you build your applications to use features from a specific Gem,
and that Gem isn't updated for 1.9.x support, that isn't Ruby's fault,
and Matz is under no obligation to make the Gem's full functionality
available in any version of Ruby.

You have the option of fixing the Oniguruma Gem to build with 1.9.x,
or migrating your code so you don't need the Gem (apparently by naming
your regexp groups).

http://redmine.ruby-lang.org/issues/show/2759

The core team still has not given me a reason for that decision.

At the time the decision was made, there was no Oniguruma Gem. Using
both named and unnamed capture groups at the same time is an ugly
thing to do, and nobody saw a good reason to enable it.

It seems to me that the problem is that the people who put together
the Oniguruma Gem made it allow more things than Ruby 1.9.x, leading
you to depend on that extra functionality-- but they then failed to
make the Gem work with 1.9.x. Again, not Ruby's fault. If I were in
your position, I'd be peeved at the people who put the Gem together.

What I am saying is "bridge". Think of a bridge as 1.8.8 to version 1.9.2.

So what are you suggesting for 1.8.8 that isn't new functionality, but
helps bridge to 1.9.2?

mathew

URL:http://www.pobox.com/~meta/

=end

[zdavatz (Zeno Davatz)]

=begin
Dear Chuck

Just for my understanding:

Ruby 1.8.6 is very stable. So is Ruby 1.8.7 less stable then Ruby 1.8.6 because it is an uneven number?

Ruby 1.9.2 is stable. But Ruby 1.9.1 is development. That is what you taught me.

If so, I would expect, that Ruby 1.9.1 breaks things, but Ruby 1.9.2 does not. So grandmother users should always be able to hopp from even to even. In this case they would hopp from 1.8.6 to 1.8.8 to 1.9.2.

But this does not seem to be the case. And that also confused Lucas Nussbaum.

Best
Zeno
=end

[zdavatz (Zeno Davatz)]

=begin
Dear Mathew

I like that "should" - lets work towards that goal.

According to what Yui Naruse told me Oniguruma was decided to be merged into 1.9 in 2002, see http://redmine.ruby-lang.org/issues/show/4239#note-13. I do not understand why. In my opinion it should have been merged into 1.8.6 and then Ruby 1.9 should have been build on 1.8. So there your "should" would have worked out perfectly well. Because there would not have been such a strong modularization of Ruby. But again that is fundamental. Micro-Kernel vs Monolithic Kernel.

We do not use the oniguruma gem we use the Oniguruma 2.5.8 patch that only works upto Ruby 1.8.6. That is why I want it in Ruby 1.8.8. And there I feel with Michael Fellinger. Bridge the gap.

And this is the point where I think there is some kind of communication problem. But I hope I can help to bridge that out so less people get burned by the "strange" ruby versioning in the future.

Best
Zeno
=end

[lucas (Lucas Nussbaum)]

=begin
On 22/01/11 at 06:10 +0900, Zeno Davatz wrote:

Issue #4239 has been updated by Zeno Davatz.

Dear Chuck

Just for my understanding:

Ruby 1.8.6 is very stable. So is Ruby 1.8.7 less stable then Ruby 1.8.6 because it is an uneven number?

Ruby 1.9.2 is stable. But Ruby 1.9.1 is development. That is what you taught me.

If so, I would expect, that Ruby 1.9.1 breaks things, but Ruby 1.9.2 does not. So grandmother users should always be able to hopp from even to even. In this case they would hopp from 1.8.6 to 1.8.8 to 1.9.2.

But this does not seem to be the case. And that also confused Lucas Nussbaum.

No, that did not confuse me. I do not confuse Ruby versioning with
kernel versioning, or GNOME versioning, or whatever. Please do not put
words in my mouth.

My problem with the high number of branches is that I have the
impression that the Ruby developers spend a lot of time maintaining a
lot of branches, and that for several of the branches, there's no clear
goal.
For example, it is not clear whether it's worth investing time in the
1_8 branch, because it's not clear whether there will be a 1.8.8 release
or not. This discussion is very welcomed, but I have the feeling that it
could have happened 2 or 3 years ago, and that would have spared a lot
of time and made 1.9.X ready earlier.

Your definition of stability seems to be "compatibility with 1.8.6". So
yes, 1.8.6 is very stable, 1.8.7 is less stable, and 1.9.2 is clearly a
lot less stable according to your definition. There are reasons why
breaking compatibility is sometimes a good thing, even if breaking
compatibility for fun is of course a terrible thing.

The real measure of stability is the amount of bugs, and a bug is a
difference between an intended behaviour and the real behaviour. If Ruby
developers decide that 1.9.X should behave differently from 1.8.6, then
a different behaviour is not a bug.

• Lucas

=end

[matz (Yukihiro Matsumoto)]

=begin
Hi,

In message "Re: [ruby-core:34773] [Ruby 1.8-Feature#4239] Let's begin a talk for "1.8.8" -- How's needed for surviving 1.8?"
on Sat, 22 Jan 2011 06:19:36 +0900, Zeno Davatz [e-mail] writes:

|According to what Yui Naruse told me Oniguruma was decided to be merged into 1.9 in 2002, see http://redmine.ruby-lang.org/issues/show/4239#note-13. I do not understand why. In my opinion it should have been merged into 1.8.6 and then Ruby 1.9 should have been build on 1.8. So there your "should" would have worked out perfectly well. Because there would not have been such a strong modularization of Ruby. But again that is fundamental. Micro-Kernel vs Monolithic Kernel.
|
|We do not use the oniguruma gem we use the Oniguruma 2.5.8 patch that only works upto Ruby 1.8.6. That is why I want it in Ruby 1.8.8. And there I feel with Michael Fellinger. Bridge the gap.

So do you really mean to suggest throwing away our work of 8 years,
just because a third party patch does not work on the latest stable
version?

						matz.

=end

[headius (Charles Nutter)]

=begin
I cannot comment on C Ruby 1.9.2 behavior. I also can't comment on the pg gem, since we don't use it for JRuby.

On JRuby, Hash is insertion-ordered. This is the same for 1.8 and 1.9 modes, on any platform, on any JVM.

JRuby does not use the pg gem because C extensions impose too many limitations on JRuby deployment. Postgresql is accessed via JDBC when running on JRuby. I can't comment on whether it would work better for your particular scenario.

My comments were intended only to clarify that I believe insertion-ordered Hash has become the standard for Ruby. I don't see why that should change because one extension is buggy and depends on an old (arbitrary) Hash ordering.

The options for Zeno seem fairly clear to me:

• Fix the issues in the pg and dbi libraries. Just because hashes are ordered and insertion is disallowed during iteration doesn't mean Ruby is wrong.
• Use something else and see if it works. There's a JRuby version of dbi you could try to use, or JRuby + JDBC directly. I'm sure there are other options for MRI a well.
  =end

[zdavatz (Zeno Davatz)]

=begin
Dear Lucas

Now this is interesting:

Quote Lucas N.:

My problem with the high number of branches is that I have the
impression that the Ruby developers spend a lot of time maintaining a
lot of branches, and that for several of the branches, there's no clear
goal.

Obviously that is exactly what I mean by Micro-Kernel. Everything gets "moduled" out. Nothing gets patched in. To many developers spend too much time on to many dead end details instead working together (Hash-Iteration is one such dead-end detail. Still no proof of a particular example that breaks a real-Life application). And that is where the problems start the longer you go. That is why there is no big Micro-Kernel Success-Story. That is why I vote for the monolithic model aka the Kernel Model where patches get applied sooner rather then later. Rather then never.

It is a fundamental process enhancement but I think that is necessary and obviously the discussion seems welcome even if it is late.

I also think that there should be a list of gems, call them "enterprise gems", that have passed an amount of downloads, say on Rubygems.org, that have to be considered BEFORE a new Ruby-Version is released by the Top-Down approach.

I think Ruby should care about the popular gems as well. Gem-Maintainers and Ruby-Developers should work better Hand in Hand. And this is a clear Critique of Matsumoto-san: I think he does not care enough about popular gems. I think he just could not care less and I do not understand why. I mean all the gems are written in Ruby!

Linus cares a lot about popular stuff in the Kernel. He tries not to break popular features when introducing new features to the Kernel. This is important!

Best
Zeno
=end

[zdavatz (Zeno Davatz)]

=begin
Dear Matsumoto-san

Thank you for your reply.

Your question is rhetorical, not practical. No I do not suggest that.

I suggest for the Future that you should make and maintain a list of the most popular gems and their maintainers, that you consult before you release a new Ruby-Version. And if a gem is very, very popular but the owner is gone then you should try personally to find a new owner for the gem (invest personal time, show personal care about the gem), just to keep the Eco-System running and evolving.

Ruby is popular and attractive because of its gems. If you do not care about the gems you will kill the Eco-System every time you release a new Ruby Version.

Also I think that patches should not be cherry-picked by their best features. They should be merged more aggressively so we have less dead-end projects, of which we do not know where they are going. The Oniguruma-Patch was Cherry-Picked for its best features. I still have no answer why that was done.

I also think that switching to a new version of Ruby should not break existing Software that runs on a current version of Ruby, specially not so if that Ruby-Software uses some very popular gems.

Popular-gems with many downloads tell you something: They tell you that many people use them and if they stop working with a new Ruby Version you will give a hard time to all of their Users. Ergo you will make upgrading to a new Ruby-Version more difficult for your existing Ruby-Users.

People say: mod_ruby is dead, it has not been maintained since 2008. Switch to Ruby 1.9.2 and Mongrel it is the best thing in the world. Well first of all that is not true, Shugo-san wants to continue his development of mod_ruby (I know because I asked him personally via Twitter), and second mod_ruby is very fast and highly reliable even if it has not been maintained a lot since 2010.

So a lot of people try to push me to Ruby 1.9.2 but hey, they obviously do not make a living of their Apps and they do not really use the gems we use every single day. They do not see that if you upgrade your App all of a sudden dbi stops woking, pg stops working, Oniguruma works completely differently, etc. I do not blame them for that. But people who talk about gems they do not use on a production basis trying to push other people to a new Ruby-Version that breaks a lot of things, well that is not such a good idea.

I do not think that Ruby just wants to be cool. I think Ruby should also be more consistent. Less dead-ends more integration through the leader himself.

Best
Zeno
=end

[duerst (Martin Dürst)]

=begin
Hello Zeno,

In a separate thread, you claim that Ruby is inconsistent because it did
not include your favorite patch. But with regards to Regexp behavior,
the inconsistency is just because of the patch you applied on your own,
there is no inconsistency for somebody who just used Ruby. It was simply
your decision to apply that patch, and it's your job to live with that,
and I hope you can stop soon to blame the core Ruby people.

In this thread, your issue is that your rely on a subtle behavior of an
iterator when the underlying collection is changed while the iterator is
running. Reasonably experienced programmers know that that's risky,
unless the spec clearly says that this is guaranteed behavior (which I
don't think it ever did). You (or somebody else, who wrote these gems)
took that risk. Now you should just fix things up rather than again
blame others.

[Just for the record, I have taken that risk, because it feels great if
it works, but I wouldn't dare to blame somebody if it stopped working,
and I would think very carefully about using this kind of stuff in
production code. I have also done other things, such as using some 1.9
feature in some code and later realizing that I had to deploy the code
with Ruby 1.8, so I had to go back and fix it. Again, I knew that was my
mistake and didn't blame others.]

Regards, Martin.

On 2011/01/21 18:46, Zeno Davatz wrote:

Issue #4239 has been updated by Zeno Davatz.

Dear Yui-san

Please correct me if I am wrong but in

http://redmine.ruby-lang.org/issues/show/1535

Yusuke Endoh says that

But I agree with Run Paint Run Run's opinion. It may lead to difficult bug to indeterminately fail to add a new key.

but that is not at all proven by Run Paint Run Run case. Then Matz goes ahead and flags that unproven claim as ok and Ruby 1.9.2 is pachted and more inconsistency is created, based on some bug that "!may!" happen in the future.

Our case of http://redmine.ruby-lang.org/wiki/ruby-19/%23Hash_Iteration is a very simple practical Live-Software Hash iteration Case that works in Ruby 1.8.6, 1.9.1 and then breaks in 1.9.2 because of some theoretical "may".

In my opinion this is not practical thinking it is theoretical thinking based on ifs and whens.

I would recommend you should at least have one practical Use-Case (running live Software or gem) that shows that his/her application(s) becomes broken before you do changes based on some "maybe".

And the moment your "maybes" break existing software and that is wrong. That is not good. That is not consistent.

Best
Zeno

http://redmine.ruby-lang.org/issues/show/4239

---

http://redmine.ruby-lang.org

--
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp mailto:[e-mail]
=end

[duerst (Martin Dürst)]

=begin
Hello Zeno,

In a separate thread, you claim that Ruby is inconsistent because it did
not include your favorite patch. But with regards to Regexp behavior,
the inconsistency is just because of the patch you applied on your own,
there is no inconsistency for somebody who just used Ruby. It was simply
your decision to apply that patch, and it's your job to live with that,
and I hope you can stop soon to blame the core Ruby people.

In this thread, your issue is that your rely on a subtle behavior of an
iterator when the underlying collection is changed while the iterator is
running. Reasonably experienced programmers know that that's risky,
unless the spec clearly says that this is guaranteed behavior (which I
don't think it ever did). You (or somebody else, who wrote these gems)
took that risk. Now you should just fix things up rather than again
blame others.

[Just for the record, I have taken that risk, because it feels great if
it works, but I wouldn't dare to blame somebody if it stopped working,
and I would think very carefully about using this kind of stuff in
production code. I have also done other things, such as using some 1.9
feature in some code and later realizing that I had to deploy the code
with Ruby 1.8, so I had to go back and fix it. Again, I knew that was my
mistake and didn't blame others.]

Regards, Martin.

On 2011/01/21 18:46, Zeno Davatz wrote:

Issue #4239 has been updated by Zeno Davatz.

Dear Yui-san

Please correct me if I am wrong but in

http://redmine.ruby-lang.org/issues/show/1535

Yusuke Endoh says that

But I agree with Run Paint Run Run's opinion. It may lead to difficult bug to indeterminately fail to add a new key.

but that is not at all proven by Run Paint Run Run case. Then Matz goes ahead and flags that unproven claim as ok and Ruby 1.9.2 is pachted and more inconsistency is created, based on some bug that "!may!" happen in the future.

Our case of http://redmine.ruby-lang.org/wiki/ruby-19/%23Hash_Iteration is a very simple practical Live-Software Hash iteration Case that works in Ruby 1.8.6, 1.9.1 and then breaks in 1.9.2 because of some theoretical "may".

In my opinion this is not practical thinking it is theoretical thinking based on ifs and whens.

I would recommend you should at least have one practical Use-Case (running live Software or gem) that shows that his/her application(s) becomes broken before you do changes based on some "maybe".

And the moment your "maybes" break existing software and that is wrong. That is not good. That is not consistent.

Best
Zeno

http://redmine.ruby-lang.org/issues/show/4239

---

http://redmine.ruby-lang.org

--
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp mailto:[e-mail]

=end

[rosenfeld (Rodrigo Rosenfeld Rosas)]

=begin
On 22-01-2011 07:31, Zeno Davatz wrote:

Issue #4239 has been updated by Zeno Davatz.

Dear Matsumoto-san

Thank you for your reply.

Your question is rhetorical, not practical. No I do not suggest that.

I suggest for the Future that you should make and maintain a list of the most popular gems and their maintainers, that you consult before you release a new Ruby-Version. And if a gem is very, very popular but the owner is gone then you should try personally to find a new owner for the gem (invest personal time, show personal care about the gem), just to keep the Eco-System running and evolving.
...

Zeno, you seem to take a lot of wrong assumptions about Ruby developers.
They don't do development for living, they don't like the current Ruby's
development approach, etc.

That is not the feedback I get from most rubysts, but just for some of
them. So I would say there is nothing wrong in the Ruby language
evolution and its ecosystem. If you want a somewhat static language, you
should choose Java or C++. Ruby is getting traction not only because of
its gems but because of the language itself. And it wouldn't have
achieved that if it has remained static along the years only improving
keeping backward compatibility.

The Ruby community has good habits like writing automated tests for
their application, so that they can more easily upgrade their Ruby and
gem versions and fix whatever is broken. If some gem is unmaintained,
you should stop using it anyway... That is how the Ruby community feels
about the subject and you are wasting your and our times trying to make
Ruby development model be similiar to the Kernel/MS
Windows/Java/Whatever one. Ruby is special in so many ways and its
development model is one of the keys that allows that. I don't see
nothing wrong with the current approach (except that I would prefer Ruby
to change to Git, but that was already discussed in another thread),
although I understand that developers are different. Some developers
don't want to write automated tests. They don't want to rewrite working
code while upgrading. They don't like changes very much. I just think
that they should choose a language that fits their philosophy, instead
of trying to change the language philosophy to fit their's. Java 7 is
taking several years to get approved and has no significant changes.
Perl 6 will probably bit the record for some language to be released,
but that is ok, since it is fundamentally another language that couldn't
be called Perl anymore, and that is a good think. I was a happy Perl
developer before I knew Ruby. And I'm inclined to go back to Perl 6 when
it is finished, since it has lots of great features. But that is how the
communities are. They are what they are and they won't change fundamentally.

I don't mind when you try to convince us that Ruby should change in some
way. I'm just writing this because I'm tired of seeing you talking about
Ruby developers when you don't know them. You may know some of them but
you can't talk in name of all of them or in name of Lucas Nussbaum as
you've just did if you can't know what you are talking about. Please,
talk in the first person.

I take my hat off to Matz and all ruby-core developers and I feel most
Rubysts do the same. So I would like to take the chance to thank you
all. I guess you are already trying to ignore some comments on this
thread, but anyway, if some of you may be confused, I just wanted to
make sure that there are developers that approve your work and your
development model, evolving fast even if it means breaking compatibility
from time to time. I know others disagree, but I want to say that I
agree with this model.

Thanks, Rodrigo.

=end

[Cezary (Cezary Baginski)]

=begin
On Thu, Jan 20, 2011 at 06:30:29PM +0900, Zeno Davatz wrote:

Issue #4239 has been updated by Zeno Davatz.

Dear Zeno,

Thank you for your deep concern and support of making it easier to
move from Ruby 1.8 to Ruby 1.9. I understand that major breakage can
be very frustrating and people tend to then generalize things.

I hope I can be of help by reducing the amount of effort put into this
discussion and come to quick conclusions. I see that most (if not all)
people on this list are more clever and knowledgeable than myself.
And also extremely helpful and responsive, respectful, polite and
direct. I hope I can learn the same.

This is why I trust the core team with almost all the technical and
political decisions, changing my code and habits to adapt. Unless
something obviously wrong comes up (e.g. a segfault).

I also feel assured that any risky proposal will quickly be noticed by
the many experts subscribed to this mailing list. I also trust that
any changes breaking compatibility are well thought out, and after a
lot of digging, they always turned out for the better (like m17n, for
example).

As I continue to read messages from this list, my respect for the
whole community continues to grow.

With so much happening in the programming world today, keeping Ruby a
great language to use (the goal) probably requires more work and
sacrifice, than it probably seems from the outside. I personally would
at least prefer to "stay out of the way" if possible.

I understand that you can be frustrated with the amount of costs
necessary to "port" an application from Ruby 1.8 to the 1.9 -
intentionally a different "dialect" if you will.

So, please allow me to respectfully disagree with you, on issues which
(IMHO) are not really aligned to the philosophy of Ruby or even
related to Ruby itself.

• comparing Linux kernel development with Ruby doesn't make sense
  (comparing with GCC/c++0x would more likely make much more sense)
  Elaborating on this within this list would be pointless, but feel
  free to contact me if you want an explanation.

• arguing that consistency and compatibility is very important from
  Ruby core-devs point of view, instead of treating it as a specific
  problem specific to you and your business (e.g. agile
  methodologies promote "embracing change" as a solution)

• stating modularity of microkernels as a better way of adding
  changes, instead of allowing more modularity in your own
  applications the amortize long term changes in Ruby. Basically you
  should have a compatibility layer over every assumption about
  external library and behavior that can change during your
  product's lifecycle

• expecting additional compatibility work from core team to reduce
  your own business costs, that could have been avoided by the same
  things I try to do, which are:

  • follow Ruby core list to discover incompatibilities years
    before they become official

  • work on and experiment with ruby-head to mitigate business
    risks before you are left with broken software and missed
    deadlines.

  • ask about breakage as soon as it happens (test trunk versions
    of software critical to your business for early warnings)

  • use extensive test suites (TDD, BDD) which allow you to make
    drastic adaptations while minimizing quality impact - even
    when outsourcing

  • strategic thinking when selecting a language for critical
    projects (maybe JAVA or COBOL would be better - they survived
    a very long time and many corporations still rely on them)

  • not giving a reason why you must switch to Ruby 1.9 (or
    forgive me if I missed it, but you should have made it more
    clear than comparisons with kernel development)

• not providing patches, fixes and concrete examples/problems but
  instead expecting core team do something that is a complete waste
  of excellent minds: 'maintenance' work, that is actually your
  responsibility towards your own clients.

Yes, Ruby is "cool" but in my respect it cares to much about the
coolness and the HIP-Style and not enough about consistency.

I see Matz providing the next generations of software developers
with tools they enjoy and make them productive for any worthwhile
project - corporate or not. I believe this goal is unique among
languages.

In my opinion, focusing on realizing visions of a great future,
while sacrificing near-team goals denotes strategic thinking that
require great resources, determination and obviously, knowledge.

Something to be envied by corporations and businesses. And not waved
of as a pursuit of "coolness" or being "hip".

The bigger your App grows the more important consistency is.

And over the years, the more difficult it will become to hire great
individuals that would prefer to maintain an obsolete project
instead of rewriting it from scratch in less time using advanced
languages and tools designed specifically with that in mind.

If you would want to continue this discussion outside this list, I
would be more than happy to provide you with what little advice and
feedback I can. This includes cases where I have misunderstood or need
to be corrected.

Otherwise, I would prefer to leave non Ruby-development discussions
from distracting others away from the important issues that are being
solved. And to prevent opinion wars from flooding this list.

I hope your bad experiences will pale in comparison to the benefits
you have gained from choosing Ruby.

And I apologize to everyone on the mailing list if I went to far with
my reply or its length.

Cheers,

Cezary

--
Cezary Baginski

Attachment: signature.asc
=end

[drbrain (Eric Hodel)]

=begin
On Jan 22, 2011, at 1:31, Zeno Davatz [e-mail] wrote:

I suggest for the Future that you should make and maintain a list of the most popular gems and their maintainers, that you consult before you release a new Ruby-Version. And if a gem is very, very popular but the owner is gone then you should try personally to find a new owner for the gem (invest personal time, show personal care about the gem), just to keep the Eco-System running and evolving.

This is an untenable chicken and egg suggestion.

With all due respect to the authors of pg and dbi, neither gem could be considered popular by download counts.

It is too bad you can not be swayed by reason and will always shift your argument to a new problem when stuck instead of meaningfully contributing or admitting some fault.

=end

[zdavatz (Zeno Davatz)]

=begin
Dear Rodrigo

Me to, I think it is good if Ruby would change to Git.

Dear Cezary

I think modularity of Micro-Kernels is not good. I believe in the Monolithic approach of the Linux Kernel. I do not know if you understood what I mean by that. But you can search for the Tanenbaum-Torvalds debate ;) - you know what side I am on. There is no big success story of a Micro-Kernel.

Why do we have to Switch to Ruby 1.9? Good question. There is not a reason per se. Just that a lot of people like to say: "Switch to Ruby 1.9, it is great". Well I can not yet confirm that, as it still breaks too many important things for us. Switching to Ruby 1.9.2 at the moment would be because of hear-say. I see no hard-facts for myself at the moment (stability and speed of our App in 1.8.6 was very hard earned for us). And then again, switching because we use Ruby is a reason per se. Why do I like to upgrade my Kernel with every RC-Release? Well because it is a lot of fun to do it! It is fun to catch Linus in a moment of despair ;) where my Kernel panics at boot. It is fun because it almost never happens. And because it almost never happens I get more time to test the really new features in every RC-Release. It is an adventure with a guiding hand.

What I would like to know is why Engine Yard wants to stick with 1.8.6 as Yui-san says.

Dear Eric

There can be other ways of measuring the success and the importance of a gem for the Ruby Eco-System. That is just a proposal.

I admit every fault that is a fault. I am not perfect, actually quite the opposite. But I do have an opinion.

I think there should be some kind of system that manages the dependency between Ruby versions and gems. But it needs to do so in a practical way. I will think some more about that.

Best
Zeno
=end

[Cezary (Cezary Baginski)]

=begin
On Sun, Jan 23, 2011 at 05:18:05AM +0900, Zeno Davatz wrote:

Issue #4239 has been updated by Zeno Davatz.

I think there should be some kind of system that manages the
dependency between Ruby versions and gems.

Testing for specific features makes more sense in Ruby's case, e.g:

do_something_with_encoding if defined?(Encoding)

The only sane way to work around dependency problems (which are
actually feature based) is making things version-independent. This
means:

1. reporting bugs and submitting patches

2. writing tests to prevent regressions (TDD/BDD)

3. adding warnings to give people time to migrate

4. dropping support for obsolete functionality when the above to
   start to cost too much

Fixing problems and avoiding dependencies is a better goal than better
dependency management, especially since some things will be broken on
the Ruby-patch-number/gem subfeature boundary.

Cheers,

Cezary

--
Cezary Baginski

Attachment: signature.asc
=end

[zdavatz (Zeno Davatz)]

=begin
Dear Cezary

Thank you for your reply.

As Chuck recommended to me privately I tried to document the problem in Ruby-Talk: http://www.ruby-forum.com/topic/939716#977061

You know, what freaks me out is that something like our ODBA -Software does flawlessly work in Ruby 1.8.6 and in Ruby 1.9.1 but then in Ruby 1.9.2 - BAMM BOUM BAMM-it breaks and it smashes you right in the face. And then you need to go backtracking right through dbi, dbd-pg, pg just to find error (and again all of that worked in 1.8.6 and 1.9.1). Now we are comparing the Ruby processes on Ruby 1.9.1 and Ruby 1.9.2 when our software starts up.

Somebody - please - really needs to write an essay about Ruby versioning policies so dumb people like myself can understand that as well. And please do not make that super-über-cool. Just make it normal, so the dumbest people can understand it. If I Google for Ruby Versioning Policies I get the Rubygems policies first. Well that I think is not good. Where are the core Ruby-Versioning policies written by Matsumoto-san?

It does not seem like organic growth to me. But Obviously Ruby does NOT grow the organic way. As far as I can tell Ruby grows by a functional top-down approach.

So please please please send the links my way so I can understand for the future how Ruby-Versioning works.

Thank you!

Best
Zeno
=end

[zdavatz (Zeno Davatz)]

=begin
Ok, the dbi gem does have some hickups to solve in Ruby 1.9.2

DBI:

1. Hash iteration breaks in Ruby 1.9.2
2. Force the Array - works for Ruby 1.9.1 and Ruby 1.9.2

http://dev.ywesee.com/wiki.php/Gem/Dbi

Specially for point 2. we do not yet know why this works in Ruby 1.9.1 and needed a change for Ruby 1.9.2.

So maybe this should be considered for Ruby 1.8.8 if that should be a bridge to Ruby 1.9.2.

Any Feedback is welcome.

Best
Zeno
=end

[rue (Eero Saynatkari)]

=begin
On 2011-01-24, at 18:19:02, Zeno Davatz wrote:

Issue #4239 has been updated by Zeno Davatz.

Ok, the dbi gem does have some hickups to solve in Ruby 1.9.2

The DBI gem is deprecated (as you can see on rubygems.org),
and succeeded by rdbi. You should use that if possible, there
shouldn't be much modification needed.

I'm not sure where the problem is with the two specific points,
but:

1. Hash iteration breaks in Ruby 1.9.2

1.9.2 Hash is ordered but for portability you could do a
hash.keys.sort.each {|e| … } if you need to rely on the
keys having a specific ordering.

2. Force the Array - works for Ruby 1.9.1 and Ruby 1.9.2

Array#push appends the given object to the end of the
Array, so it doesn't do anything special with #to_a
objects (since you might want to actually store those).

E

Sent from my rotary phone using an enormous number of revolutions.

=end

[lsegal (Loren Segal)]

=begin

On 1/24/2011 11:19 AM, Zeno Davatz wrote:

Ok, the dbi gem does have some hickups to solve in Ruby 1.9.2

> Specially for point 2. we do not yet know why this works in Ruby 1.9.1 and needed a change for Ruby 1.9.2.

1.9.1 was the first release in the "1.9" series. It was ultimately not
meant to be a stable branch and not meant to be used in production code.
This is why Rails does not [officially] support 1.9.1. You should learn
lessons from other projects and do the same. You shouldn't be discussing
1.9.1 at all.

So maybe this should be considered for Ruby 1.8.8 if that should be a bridge to Ruby 1.9.2.

What are you asking to be considered, exactly? It's not ruby-core's
responsibility to fix third-party gems. If gem X doesn't work for you,
report the bug with the gem's authors and have it fixed to work in 1.9.2.

Secondly, it's been nearly 100 emails and you've yet to explain how a
1.8.8 will bridge to 1.9.2 any differently than 1.8.6 or 1.8.7. Hash
iteration will still be what it is in 1.9.2, regardless of what it
changes to in 1.8.8. So here are the two possible outcomes of a new
minor in the 1.8 series:

1. 1.8.8 doesn't change hash iteration and your dbi gem still works--
   but you still have to find a new gem to complete the upgrade to 1.9.2
2. 1.8.8 DOES change hash iteration and the dbi gem breaks. You still
   have to find a new gem, this time for 1.8.8.

In either case you have to find a new gem. So how about you short
circuit the paths and just go find a new working gem already? A few
alternatives were proposed in this thread, and your application could
have been up and running in 1.9.2 by now.

• Loren

=end

[zdavatz (Zeno Davatz)]

=begin
Dear Eero

Thank you for the Feedback. I will test rdbi asap.

Dear Loren

Yes, our new App for Ruby 1.9.2 is up and running now with the changes made to dbi. I have not yet tested rdbi. That will follow at some time.

I guess Ruby-Versioning is still a bit of a secret these days. I do not feel that it is 100% transparent. But maybe I also just do not understand it. Plus Ruby does have a Top-Down-Approach. I was not aware of that.

Time will help.

Thanks for all the replies.

Best
Zeno
=end

[zdavatz (Zeno Davatz)]

=begin
BTW. Japanese speakers probably already now of this.

With this Ruby-Extension, Hash-Iteration will work both with Ruby 1.9.1 and Ruby 1.9.2 - No more getting screwed by DBI gem 0.4.5 if you apply this to your code.

http://url.ba/okfh

This is our slight improvement to the "patch". Hope this will make it into Ruby 1.9.3.

http://url.ba/37xy

Maybe this can even be applied for Ruby 1.8.8. That we have not yet tested ;)

Thank you NOBUOKA Yu / 信岡 ゆう sama.

Best
Zeno
=end

[shyouhei (Shyouhei Urabe)]

• Status changed from Open to Assigned

[shyouhei (Shyouhei Urabe)]

=begin
Hi, I happened to notice this being assigned to me. So I describe the status in short:

"No core developers are currently willing to release 1.8.8."

Core people are more and more getting interested in 1.9 development. Of course you can fork the project so it is technically possible for you to have YOUR OWN 1.8.8, but I think that would rarely happen. So it is almost certain, that there will be no 1.8.8.

1.8.7 support continues for a while, FYI.
=end

[headius (Charles Nutter)]

=begin
Good news, Shyouhei! This will help encourage us to move JRuby to 1.9
compatibility by default in the near(er) future.

• Charlie

On Tue, Apr 5, 2011 at 3:21 AM, Shyouhei Urabe [e-mail] wrote:

Issue #4239 has been updated by Shyouhei Urabe.

Hi, I happened to notice this being assigned to me.  So I describe the status in short:

"No core developers are currently willing to release 1.8.8."

Core people are more and more getting interested in 1.9 development.  Of course you can fork the project so it is technically possible for you to have YOUR OWN 1.8.8, but I think that would rarely happen.  So it is almost certain, that there will be no 1.8.8.

1.8.7 support continues for a while, FYI.

Feature #4239: Let's begin a talk for "1.8.8" -- How's needed for surviving 1.8?
http://redmine.ruby-lang.org/issues/4239

Author: Shota Fukumori
Status: Assigned
Priority: Normal
Assignee: Shyouhei Urabe
Category: core
Target version: Ruby 1.8.8

 ###########################
 # This issue is translated from #4207.
 # For Japanese: This translation needs proofreading. If you have a patch, please send to sorah[at]tubusu[dot]net.
 # Newer version of translation available at: https://gist.github.com/b2c4f223d3ee0bca72ad
 ###########################

 # http://redmine.ruby-lang.org/issues/show/4207
 = Let's begin a talk for "1.8.8" -- How's needed for surviving 1.8?

 Hi,

 I know that we cannot release ruby_1_8 branch... more than anyone.

 But the time past 3 years from 1.9.0, and 2.5 years from 1.8.7;
 it will be turned to 3 years in June 2011.

 Why I'm marking "3 years," because releasing interval over 3 years
 first time ever, and almost systems have revised after 3 years from
 developed in my experience... so, almost codes which targets 1.8.7
 preparing to revised; I think.

 Well, Which version used when codes which targets 1.8.7 are revised,
 I recommend 1.9.2 on my post, but almost can't use 1.9.x in
 actuality. Like, Extension libraries doesn't work.
 When can't use 1.9.x in codes, so it means use only 1.8.7. but it is
 really tough, for making tasks with 1.8.7, and I think that when I
 can give up maintaining 1.8.7? when my motivation is decreasing in
 future, it won't increase again. So I want to use new version,
 and don't use 1.8.7. New codes must target newer versions.

 So, I want to set directions about 1.8.x future. I'm considing that
 destroy ruby_1_8 branch and we won't release 1.8.8 for a one of
 ideas. If we won't release 1.8.8, it means that can publish
 announcement about 1.8.7 is last version of 1.8 branch,then 1.8
 goes to last maintainance release. ah, in simplicity developers
 task is decreased; developers will be happy.

 P.S.: I hope that people in a posision like Endoh Yusuke at 1.9.2.
 Anyone?

 ###
 # http://redmine.ruby-lang.org/issues/show/4207#note-6

 Well, Organize this issue without my factors, currently we have the following
 issues of 1.8.8.

 * the time past 3 years from 1.9.0 released. In last 3 years, We released
  1.9.2 smoothly at 1.9 branch. Thanks Yugui (Yuki Sonoda).
  Also many users are using 1.9.x at forms of RailsDevCon.
  http://railsdevcon.jp/RailsDevCon2010report.pdf
 * 1.8.8 (and 1.8.7?) is on migration step to 1.9, but if we continue
  developing 1.8.8 at this rate and release 1.8.8 in 2020, do users which
  haven't migrated to 1.9 exist?
 * Currently does ruby_1_8 include any prompting structures to migrate
  1.9.x more than 1.8.7 at all? Just not merged same patches as 1.9?
 * "I want to release so I release. Any users didn't effect." is a one of
  views, but it makes unhappy by recognition differences?

 So.. Because 1.8 mustn't let be uncontrolled,
  I propose the following ideas which possible:

 1. Not today but ASAP, release 1.8.8 as "better 1.8.7." Release goal is this
   Summer.
 2. Develop 1.8.8 until it's approached to ideal. Users can't be affect.
   Release goal is 2020 Christmas.
 3. We won't release 1.8.8 never. Drop.
 4. Otherwise I haven't thought yet.

 I don't specify any idea for adoption.
 Anyhow, I think that 1.8 mustn't keep current principle, so I asking "What do we do?"

 Well.. what do we do?

--
http://redmine.ruby-lang.org

=end

[shyouhei (Shyouhei Urabe)]

• Description updated (diff)
• Status changed from Assigned to Closed

This target version no lnger exists. I'd like to take this opportunity to thank you all.