[#37730] [Ruby 1.9 - Bug #4962][Open] come back gem_prelude! — Yusuke Endoh <mame@...>

24 messages 2011/07/02

[#37840] [Ruby 1.9 - Feature #4985][Open] Add %S[] support for making a list of symbols — Aaron Patterson <aaron@...>

23 messages 2011/07/07

[#37866] [Backport87 - Feature #4996][Open] About 1.8.7 EOL — Shyouhei Urabe <shyouhei@...>

22 messages 2011/07/08

[#37913] [Ruby 1.9 - Bug #5003][Open] Enumerator#next segfaults in OS X Lion (10.7) — Ganesh Gunasegaran <ganesh.gunas@...>

16 messages 2011/07/09

[#37917] [Ruby 1.9 - Feature #5005][Open] Provide convenient access to original methods — Lazaridis Ilias <ilias@...>

13 messages 2011/07/09

[#37932] [Ruby 1.9 - Feature #5008][Open] Equal rights for Hash (like Array, String, Integer, Float) — Suraj Kurapati <sunaku@...>

31 messages 2011/07/09

[#37936] [Ruby 1.9 - Feature #5010][Open] Add Slop(-like) in stdlib and deprecate current OptionParser API — Rodrigo Rosenfeld Rosas <rr.rosas@...>

29 messages 2011/07/09

[#37968] [Ruby 1.9 - Bug #5015][Open] method_added" is called in addition to "method_undefined — Lazaridis Ilias <ilias@...>

14 messages 2011/07/10

[#38096] [Ruby 1.9 - Feature #5033][Open] PATCH: 1.9: gc_mark_children: Avoid gc_mark() tail recursion, use goto again. — Kurt Stephens <ks.ruby@...>

14 messages 2011/07/16

[#38109] [Ruby 1.9 - Bug #5034][Open] C Source Code formatting — Lazaridis Ilias <ilias@...>

18 messages 2011/07/16

[#38171] [Ruby 1.9 - Bug #5047][Open] Segfault (most likely involving require) — Jack Christensen <jack@...>

21 messages 2011/07/18

[#38182] [Ruby 1.9 - Feature #5054][Open] Compress a sequence of ends — ANDO Yasushi ANDO <andyjpn@...>

68 messages 2011/07/19

[#38197] [Ruby 1.9 - Feature #5056][Open] About 1.9 EOL — Shyouhei Urabe <shyouhei@...>

39 messages 2011/07/19
[#38900] [Ruby 1.9 - Feature #5056] About 1.9 EOL — Shota Fukumori <sorah@...> 2011/08/10

[#38902] Re: [Ruby 1.9 - Feature #5056] About 1.9 EOL — Yukihiro Matsumoto <matz@...> 2011/08/10

Hi,

[#39048] Re: [Ruby 1.9 - Feature #5056] About 1.9 EOL — SASADA Koichi <ko1@...> 2011/08/22

Hi,

[#39055] Re: [Ruby 1.9 - Feature #5056] About 1.9 EOL — Lucas Nussbaum <lucas@...> 2011/08/23

On 23/08/11 at 06:50 +0900, SASADA Koichi wrote:

[#38295] [Ruby 1.9 - Feature #5064][Open] HTTP user-agent class — Eric Hodel <drbrain@...7.net>

15 messages 2011/07/21

[#38391] [Ruby 1.9 - Bug #5076][Open] Mac OS X Lion Support — Yui NARUSE <naruse@...>

17 messages 2011/07/22

[#38503] [Ruby 1.9 - Feature #5096][Open] offer Logger-compatibility for ext — Eric Wong <normalperson@...>

16 messages 2011/07/25

[#38510] [Ruby 1.9 - Feature #5097][Assigned] Supported platforms of Ruby 1.9.3 — Yui NARUSE <naruse@...>

42 messages 2011/07/26

[#38526] [Backport92 - Backport #5099][Open] Backport r31875 load path performance problem — Aaron Patterson <aaron@...>

19 messages 2011/07/26

[#38538] [Ruby 1.9 - Feature #5101][Open] allow optional timeout for TCPSocket.new — Eric Wong <normalperson@...>

15 messages 2011/07/27

[#38610] [Ruby 1.9 - Feature #5120][Open] String#split needs to be logical — Alexey Muranov <muranov@...>

18 messages 2011/07/30

[#38623] [Ruby 1.9 - Feature #5123][Open] Alias Hash 1.9 as OrderedHash — Alexey Muranov <muranov@...>

14 messages 2011/07/31

[ruby-core:37882] [Backport87 - Feature #4996] About 1.8.7 EOL

From: Jon Forums <redmine@...>
Date: 2011-07-08 14:21:11 UTC
List: ruby-core #37882
Issue #4996 has been updated by 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
----------------------------------------
Feature #4996: About 1.8.7 EOL
http://redmine.ruby-lang.org/issues/4996

Author: Shyouhei Urabe
Status: Open
Priority: Normal
Assignee: 
Category: core
Target version: 


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.


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

In This Thread