Feature #4996: About 1.8.7 EOL

• Status: Closed
• Assignee: -

[shyouhei (Shyouhei Urabe)]

No, not now. Don't worry. But we have to start talking about this
topic: when and how 1.8.7 should die.

"You should really use 1.9". I have said this again and again and now
repeat it once more. As we're about to release 1.9.3 I can't but say
it is, totally wonderful. Rich features. Faster execution. Rubygems
integrated. Rails works perfectly. I've been using 1.9 for years and
now I can't go back to the days without it.

So why there's still 1.8.7? It's also clear: for system admins. So
far 1.8.7 has been adopted widely because it was a state of art ruby
implementation of the day it was released. Even after you stop
writing software for something, it needs bugfixes and maintenance
releases. For ruby 1.8.7 , that's what I'd been offering for these
three years.

Now... I know many of you're still developing your software against
1.8.7 in spite of its dead-endedness. Sooner or later the whole Ruby
community will move towards 1.9 and those 1.8.7-based systems are
expected to become unmaintained. I don't like the situation. I want
you and your system to be 1.9 ready.

So to encourage your moving towards 1.9, I think I should define
1.8.7's end-of-life to be at some point in the future. I guess you're
not moving to 1.9 because 1.8 is (or at least seems to be) maintained.
Let's stop it. We will no longer touch 1.8.7 in any way once after
the EOL. right?

My current timeline (to be rescheduled) is:

• Normal maintenance (as it is today): provided until June 2012,
• Security fixes: provided until June 2013.

Give us your opinioms.

[now (Nikolai Weibull)]

On Fri, Jul 8, 2011 at 10:17, Shyouhei Urabe [e-mail] wrote:

"You should really use 1.9".

Give us your opinioms.

As soon as 1.9 isn’t dead slow at requiring files on Windows (thanks
to stat()) there won’t be any remaining issues for my organization.

[jonforums (Jon Forums)]

So to encourage your moving towards 1.9, I think I should define
1.8.7's end-of-life to be at some point in the future. I guess you're
not moving to 1.9 because 1.8 is (or at least seems to be) maintained.
Let's stop it. We will no longer touch 1.8.7 in any way once after
the EOL. right?
...SNIP...
Give us your opinioms.

While I've moved to 1.9 exclusively on my Arch and Ubuntu systems and am pleased, on Windows the performance differences between 1.8.7 and 1.9.x are noticeable enough to continue to be a problem that causes 1.8.7 to remain attractive and slow 1.9 adoption. While the root cause may turn out to be excessive stat's, I suspect current Encoding and IO implementations on Windows also play a part.

While I understand that Windows (MinGW, MSVC, etc) is a "best efforts" supported platform, I remain surprised as to why this fundamental issue with MRI hasn't been prioritized and resourced. Specifically, I'm remain surprised for the following reasons:

• ruby-core has knowledgeable developers (Usa, Nobu, Luis, et al) with Windows expertise who are responsive to Windows-specific issues.
• Demand for Ruby on Windows is self-evident and we see that rubyforge believes there's been ~5.92 million downloads of the legacy One-Click and RubyInstaller packages.
• RubyGems works well on Windows and that team is responsive to Windows-specific issues.
• Many gem authors (Nokogiri, Thin, etc) are building (1.8/1.9) binary gems that work quite well with the MinGW-built RubyInstaller. Where binary gems don't yet exist, many times our DevKit from the RubyInstaller project allows Windows users to build from source.
• Both the JRuby and Rubinius implementations appear to be placing more emphasis on ensuring their implementations work well on Windows.

Do not perceive my feedback to be harsh or overly critical as I've been very pleased that my Windows-specific issues have been quickly addressed in the past.

However, until ruby-core realizes this Windows-specific 1.9 performance issue is critical and prioritizes it as important and resources it appropriately, the transition from MRI 1.8 to MRI 1.9 for Windows users will be hampered. Furthermore, if JRuby and Rubinius continue to prioritize Windows and MRI doesn't, MRI could quickly become irrelevant for Windows users. While I don't truly believe this, it does have a non-zero probability of occurring if we do nothing and stay the current course.

Bottom line: move forward with the 1.8.7 EOL timeline and jump in and focus resources on identifying and fixing the root cause of Windows 1.9 performance issues.

Jon

[shyouhei (Shyouhei Urabe)]

(07/08/2011 06:01 PM), Nikolai Weibull wrote:

On Fri, Jul 8, 2011 at 10:17, Shyouhei Urabe [e-mail] wrote:

"You should really use 1.9".

Give us your opinioms.

As soon as 1.9 isn’t dead slow at requiring files on Windows (thanks
to stat()) there won’t be any remaining issues for my organization.

Good news for you: one of the advantages of new 1.9.3 is the require
performance boost. You should give it a try when it appears.

[steveklabnik (Steve Klabnik)]

I think that the Python community is doing a great job with this. Their parallel situation is the move from Python 2 -> 3, and it was conceived as a five year plan, which is still being in the middle of executed.

I agree that everyone should be on 1.9 by now, but there's the ideal situation and the reality. Providing an actual statement about the EOL of 1.8.7 will enable people to be able to plan out their transitions.

[tenderlovemaking (Aaron Patterson)]

On Fri, Jul 08, 2011 at 05:17:17PM +0900, Shyouhei Urabe wrote:

So to encourage your moving towards 1.9, I think I should define
1.8.7's end-of-life to be at some point in the future. I guess you're
not moving to 1.9 because 1.8 is (or at least seems to be) maintained.
Let's stop it. We will no longer touch 1.8.7 in any way once after
the EOL. right?

FWIW, Rails 4 will only support 1.9.x. With Rails 3.1, if you generate
an application using 1.9, it will only work on 1.9.

My current timeline (to be rescheduled) is:

• Normal maintenance (as it is today): provided until June 2012,
• Security fixes: provided until June 2013.

The rails team will release 3.2 in 2012 (with 1.8 support), then I
expect 4.0 (Ruby 1.9 only) will be in 2013.

Give us your opinioms.

I can't wait to be freed from Ruby 1.8. :-)

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

[bagwanpankaj (Pankaj Bagwan)]

Thumbs Up. +1 :)

[candlerb (Brian Candler)]

I'm a lone voice in the wilderness, but when ruby 1.8 is gone, I'm gone. Ruby won't miss me, but I'll miss Ruby. I've been around since 1.6.8.

As far as I know, ruby 1.9's Encoding system is still lacking any official documentation. I reversed-engineered and documented about 200 behaviours, by which point it was abundantly clear to me that I cannot bear to use it (and yet with 1.9 it cannot be avoided). Surely computing does not need to be so difficult!

I still hold out hope that Rite, being a trimmed-down language, will have well-defined semantics.

I also note that the Ruby Specification project picked 1.8.7 as its base. Has that project been abandoned? Are all ruby implementations only going to have the MRI source code as the language reference going forward?

[drbrain (Eric Hodel)]

On Jul 23, 2011, at 12:59 PM, Brian Candler wrote:

As far as I know, ruby 1.9's Encoding system is still lacking any official documentation. I reversed-engineered and documented about 200 behaviours, by which point it was abundantly clear to me that I cannot bear to use it (and yet with 1.9 it cannot be avoided). Surely computing does not need to be so difficult!

If you point me to the documentation (and consent) I will merge it into Ruby.

[candlerb (Brian Candler)]

https://github.com/candlerb/string19/blob/master/string19.rb

I'm afraid its current format may not lend itself well to merging into Rdoc, but please feel free to use any of it as you see fit.

On Sat, Jul 23, 2011 at 4:24 PM, Eric Hodel [e-mail] wrote:

On Jul 23, 2011, at 12:59 PM, Brian Candler wrote:

As far as I know, ruby 1.9's Encoding system is still lacking any official documentation. I reversed-engineered and documented about 200 behaviours, by which point it was abundantly clear to me that I cannot bear to use it (and yet with 1.9 it cannot be avoided). Surely computing does not need to be so difficult!

If you point me to the documentation (and consent) I will merge it into Ruby.

I think this is his documentation:
https://github.com/candlerb/string19/blob/master/string19.rb

Current copyright is "all rights reserved", but I hope he will consent
to its use. :)

[normalperson (Eric Wong)]

Brian Candler [e-mail] wrote:

I'm a lone voice in the wilderness

You're not alone, I don't like the 1.9 encoding system, either; but
I primarily deal with binary data so I don't usually need to care about it
other than setting binmode on $std{in,out,err}

--
Eric Wong

[trans (Thomas Sawyer)]

@brian I basically have to concur with your sentiment. I've already had one issue with encoding where I simply could not find a solution and abandoned any effort to get 1.9 compatibility (gash gem). Basically I'm just ignoring the whole issue as I move to 1.9. If someone throws me a patch for encoding issues I'll merge, but beyond that... you are right, it too damn "difficult", and I only have a finite number cycles to give.

[judofyr (Magnus Holm)]

On Sat, Jul 23, 2011 at 23:09, Eric Wong [e-mail] wrote:

Brian Candler [e-mail] wrote:

I'm a lone voice in the wilderness

You're not alone, I don't like the 1.9 encoding system, either; but
I primarily deal with binary data so I don't usually need to care about it
other than setting binmode on $std{in,out,err}

You're not alone.

Everybody hates encoding issues. Ruby 1.9 just forces you to deal with
them, while 1.8 silently ignores them.

[shyouhei (Shyouhei Urabe)]

To: "I won't move because I don't understand 1.9" -kind of people,

Isn't it the time for you to have your own branch of Ruby just like I do now?

The world's gonna move to 1.9. You've lost your war (for at least three years now),
that's a sad thing. But we can't go back. If you don't like it, I think it's your
turn to hustle. Just fork it. You have the right to do so.

You should use 1.9, is the dogma we (core people) can't give up.

PS: For Encodings' being complicated, just curse the Babylonians.

[duerst (Martin Dürst)]

On 2011/07/24 6:26, Thomas Sawyer wrote:

@brian I basically have to concur with your sentiment. I've already had one issue with encoding where I simply could not find a solution and abandoned any effort to get 1.9 compatibility (gash gem). Basically I'm just ignoring the whole issue as I move to 1.9. If someone throws me a patch for encoding issues I'll merge, but beyond that... you are right, it too damn "difficult", and I only have a finite number cycles to give.

If you (or anybody else) has problems with string encodings, please
write to this list. There are quite a few people here who may be able to
help you.

Regards, Martin.

[candlerb (Brian Candler)]

Shyouhei Urabe wrote:

The world's gonna move to 1.9. You've lost your war (for at least three years now),
that's a sad thing. But we can't go back. If you don't like it, I think it's your
turn to hustle. Just fork it. You have the right to do so.

Indeed. The question then becomes, which is more productive? Maintain 1.8 plus all the libraries we depend on, or just move to another language like Python?

Python has quite a few ugly points (for example look how it handles 'super'), but it has semantics for strings and M17N which are both well-defined and easily understood. That clarity has made the Python 2->3 transition much smoother; indeed, they have even provided a tool which converts most Python 2 programs to Python 3.

I remember fondly the smooth transition from ruby 1.6.8 to 1.8.0 (the 'shim' library providing 1.8 features while people still had to deploy 1.6.8)

PS: For Encodings' being complicated, just curse the Babylonians.

I still assert that Ruby makes programming too hard. A statement like "a = b + c" should be easy to understand; it should be clear under what circumstances it raises an exception, and it should be clear what properties 'a' will have going forward which might the behaviour at the next point of use.

Anyway, you're right, there's nothing I can do about this. Ruby <= 1.8 is (or was) a fine language, and I shall miss it.

[spatulasnout (B Kelly)]

Thomas Sawyer wrote:

@brian I basically have to concur with your sentiment.
I've already had one issue with encoding where I simply
could not find a solution and abandoned any effort to
get 1.9 compatibility (gash gem).

Was it this issue involving \0x00 vs. \000 ?

https://github.com/judofyr/gash/issues/4

If so, it's not clear that this is an 'encoding' issue in
the sense that Brian refers to.

Brian Candler wrote:

I still assert that Ruby makes programming too hard.
A statement like "a = b + c" should be easy to understand;
it should be clear under what circumstances it raises an
exception, and it should be clear what properties 'a' will
have going forward which might the behaviour at the next
point of use.

Given duck typing and Object#extend, the meaning of
"a = b + c" has always depended upon how the particular
objects referenced by b and c respond to :+ when the
message is received.

And while this potential for unexpected behavior tends
to worry programmers used to statically typed languages,
it doesn't seem to cause problems for ruby programmers
in practice: We write "a = b + c" assuming b and c will
hold reasonable values.

In my experience so far developing applications in 1.9,
the good news is that nothing has changed.

We still write "a = b + c" under the same assumptions
as in 1.8: that the objects referenced by b and c will
will be compatible enough to meaningfully process the
:+ message.

It seems that you're concerned that b and c might
hold strings with incompatible encodings.

But from an application development perspective, this
seems to be a non-issue. The solution seems to be as
easy as picking one internal encoding for the app and
sticking with it.

I imagine writing an application that could
successfully juggle arbitrary internal encodings would
be difficult in any language. But ruby19 doesn't
require us to develop applications that way.

If feels like a case of, "Doctor, it theoretically
hurts when my ruby19 application encounters multiple
internal encodings!" Where the advice would of course
be, "Don't write it that way...?"

Regards,

Bill

[naruse (Yui NARUSE)]

B Kelly wrote:

Thomas Sawyer wrote:

@brian I basically have to concur with your sentiment.
I've already had one issue with encoding where I simply
could not find a solution and abandoned any effort to
get 1.9 compatibility (gash gem).

Was it this issue involving \0x00 vs. \000 ?

https://github.com/judofyr/gash/issues/4

If so, it's not clear that this is an 'encoding' issue in
the sense that Brian refers to.

As I commented to there, it's not an encoding issue.

[shyouhei (Shyouhei Urabe)]

=begin

Hi folks, I'd like to make an official announcement about this topic on www.ruby-lang.org.
Can you take a look at this draft? I'm sure my English is bad.

Hello, and thank you for your getting into our community.

I know most of  you more or less use version 1.8.7  of Ruby today.  It
was released  in 2008 and was  a state-of-art Ruby  release back then.
-- I am  proud to say  it is no  longer.  Ruby's core  developers have
been actively working  on their new versions, 1.9,  and they are about
to  release new 1.9.3.   I have  been using  1.9 for  years and  now I
cannot  go  back to  the  days  without  it.  Rich  features.   Faster
execution.  Rubygems integrated.  Rails works perfectly.  I cannot but
say it is totally wonderful.  Everyone please, use 1.9.

But at  the same time I  know you cannot  switch to 1.9 right  now for
various  reasons.    Maybe  you   have  already  been   deployed  your
application with 1.8.7.  Maybe you use a 3rd party library and that is
for 1.8.7 only.  Or maybe your Linux distribution only supports 1.8.7.
So I hereby announce  you how long you can stick to  it.  It is OK you
are using 1.8.7 today but after a while, it will be shut down.

Please be ready.

Schedule:

* We continue to provide normal  maintenance for 1.8.7 as usual, until
  June  2012.   You can  safely  assume  we  provide bugfixes  and  no
  incompatibility shall be introduced.

* After that we stop bugfixes.   We still provide security fixes until
  June 2013, in case you are still using 1.8.7.

* We will no longer support 1.8.7 in all senses after June 2013.

=end

[Eregon (Benoit Daloze)]

On 29 September 2011 14:51, Shyouhei Urabe [e-mail] wrote:

Issue #4996 has been updated by Shyouhei Urabe.

¾gin

Hi folks, I'd like to make an official announcement about this topic on www.ruby-lang.org.
Can you take a look at this draft?  I'm sure my English is bad.

   Hello, and thank you for your getting into our community.

   I know most of  you more or less use version 1.8.7  of Ruby today.  It
   was released  in 2008 and was  a state-of-art Ruby  release back then.
   -- I am  proud to say  it is no  longer.  Ruby's core  developers have
   been actively working  on their new versions, 1.9,  and they are about
   to  release new 1.9.3.   I have  been using  1.9 for  years and  now I
   cannot  go  back to  the  days  without  it.  Rich  features.   Faster
   execution.  Rubygems integrated.  Rails works perfectly.  I cannot but
   say it is totally wonderful.  Everyone please, use 1.9.

   But at  the same time I  know you cannot  switch to 1.9 right  now for
   various  reasons.    Maybe  you   have  already  been   deployed  your
   application with 1.8.7.  Maybe you use a 3rd party library and that is
   for 1.8.7 only.  Or maybe your Linux distribution only supports 1.8.7.
   So I hereby announce  you how long you can stick to  it.  It is OK you
   are using 1.8.7 today but after a while, it will be shut down.

   Please be ready.

   Schedule:

   * We continue to provide normal  maintenance for 1.8.7 as usual, until
     June  2012.   You can  safely  assume  we  provide bugfixes  and  no
     incompatibility shall be introduced.

   * After that we stop bugfixes.   We still provide security fixes until
     June 2013, in case you are still using 1.8.7.

   * We will no longer support 1.8.7 in all senses after June 2013.

I am not a native english speaker, but here is what I think.

I believe what you wrote is actually really good english and entertaining.

I found only one sentence which is a bit unclear:
"Ruby's core developers have been actively working on their new
versions, 1.9, and they are about to release new 1.9.3."
I would rather write:
"Ruby's core developers have been actively working on their new
version, 1.9, and they are about to release 1.9.3."

Benoit Daloze

[shyouhei (Shyouhei Urabe)]

Thank you. I published a fixed version to the website.

[jeremyevans0 (Jeremy Evans)]

• Status changed from Open to Closed