From: B Kelly Date: 2011-07-25T08:43:11+09:00 Subject: [ruby-core:38466] [Backport87 - Feature #4996] About 1.8.7 EOL Issue #4996 has been updated by 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 ---------------------------------------- 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