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

1.txt

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?

2.txt

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?

3.txt

#####
# 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 raise 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.
    * Raise warning when Block variable name and Local variable name are equal
    * magic comment; raise 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.