Hi,

NARUSE, Yui wrote:
> When this plan is decided in July, it was based on the assumption that
> most feature of Ruby 1.9 was already fixed and we could spend time to
> make ruby stable.

OK. In these several days, I understood how dynamically Ruby is changing
and that Ruby needs more changes for 1.9.x series.

> My new plan is,
> * Ruby 1.9.1 will be released in 2008-12-25.
> * Ruby 1.9.1 doesn't assure ABI Compatibility to future Ruby 1.9 series.
> * Ruby 1.9.2 may break compatibility to 1.9.1
>   if the change is allowed by people and matz and yugui.

In addition, I heard that some features will break the binary
compatibility, especially MVM.

We need to rebuild the plan for release and compatibility of 1.9.x.

(1) I'll release 1.9.0-5 tonight.
(2) We aim to release 1.9.1 on 20 Dec.
(3) After 1.9.0-5 will be released, you can change the explicitly
claimed features by 25 Oct.
 I heard
 * default_internal
 * miniunit (I reverted it, but I'll recover it after the release of
1.9.0-5)
 * cgi.rb
 * adding encodings
 * Anything M17N-releated - I think some of standard libraries need to
be changed for more supporting M17N.

 If you have another feature to be changed, claim it immediately.

(4) I will remove supports for the following platforms.
    * human68k
    * djgpp
    * Classic MacOS
    * WinCE
    * VMS
  But always welcome a patch for supporting these platforms.

(5) I will create ruby_1_9_1 branch on 25 Oct.
(6) I will release Ruby 1.9.1 Preview Release-1 on 25 Oct.
(7) After the branch created, you can change features at trunk.

(8) When a new feature or a feature change breaks backward
compatibility, the change must satisfy the following conditions.
  * It must be discussed at ruby-core, ruby-dev.
  * Matz allows it.
  * yugui allows it.

Thanks.

-- 
Yugui (Yuki Sonoda) <yugui / yugui.jp>
http://yugui.jp