[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