Forum: Ruby-dev [ANN] 1.9.2 release plan

F24ff61beb80aa5f13371aa22a35619c?d=identicon&s=25 Yusuke ENDOH (Guest)
on 2010-03-15 15:12
(Received via mailing list)
Hi,

We announce 1.9.2 release plan:

  - 31 Mar.  freeze the spec
  - 30 Apr.  freeze the code
  - 31 May.  release 1.9.2-preview2
  - 30 Jun.  release 1.9.2-rc
  - 31 Jul.  release 1.9.2-p0

The following will be proceeded at each event:


=== freeze the spec (31 Mar.) ===

* close and identify 1.9.2 feature tickets

  - 1.9.2 will NOT include all features that we cannot agree by this
    time; target of the ticket will be changed to 1.9.x
  - 1.9.2 will NOT include all features suggested after this time

  - exception: The spec detail of "DL powered by libffi" feature can
    be changed until 30 Apr., because we consider that the feature is
    important for inter-implementation compatibility.  But we will
    not allow after April.  Aaron, keep up your good work!


=== freeze the code (30 Apr.) ===

* close feature implementation for 1.9.2

  - 1.9.2 will NOT include all features that are not implemented and
    committed by this time (even if the ticket is agreed at 31 Mar.)
  - (inadvisable hint: feature request will survive as long as any
     change to aim to implement the feature is committed, even if the
     change is buggy a little)

* create ruby_1_9_2 branch

  - do NOT commit anything that breaks the frozen feature to trunk
    until this time


=== release 1.9.2-preview2 (31 May.) ===

* fix 1.9.2 feature set

  - 1.9.2 will NOT include all features that are not stable yet or that
    are considered uncompleted at this time; they will be reverted

* identify bug tickets that should be fixed in 1.9.2

  - bug tickets registered after this time will be consider; but they
    will be evaluated more conservatively (e.g., bug report based on
    just "reporter's intuition" will be rejected or deferred to 1.9.x)

* call for 3rd party to check 1.9.2-preview2

  - please check the release on various platforms
  - please check and fix "1.9-ready" projects on the release

This release may be delayed (at most) a week only if some "essential"
feature (e.g., dl on libffi) are not stable yet.


=== release 1.9.2-rc (30 Jun.) ===

* finish to fix 1.9.2 bug tickets

  - if we figure out that an issue needs major change of 1.9.2, and if
    the issue is not vital, it will be deferred to 1.9.x.

This release may be delayed as long as any bug tickets remain.


=== release 1.9.2-p0 (31 Jul.) ===

* wait for bug report in about two weeks

After that, when there is no bug ticket, 1.9.2-p0 will be released.


This plan is approved by Yugui, the 1.9 release manager.
At first, you should hurry to appeal your feature request, if any.

Thanks,
947c97a2c119e85989d2ca63135a5b5e?d=identicon&s=25 Roger Pack (Guest)
on 2010-03-15 18:23
(Received via mailing list)
> === freeze the spec (31 Mar.) ===
>
> * close and identify 1.9.2 feature tickets

One ticket I would like to bring some attention to is 2152
http://redmine.ruby-lang.org/issues/show/2152

It would indeed be kind to decide on this detail before the code freeze.



> Thanks,

Thank you for doing the work.
-rp
204784d162fece694532d2ef5cdc5ca5?d=identicon&s=25 Hongli Lai (Guest)
on 2010-03-15 19:40
(Received via mailing list)
I'd like to bring attention to:
http://redmine.ruby-lang.org/issues/show/2629
It is a potential API change.
F24ff61beb80aa5f13371aa22a35619c?d=identicon&s=25 Yusuke ENDOH (Guest)
on 2010-03-17 15:10
(Received via mailing list)
Hi,

2010/3/16 Hongli Lai <hongli@plan99.net>:
> I'd like to bring attention to:
> http://redmine.ruby-lang.org/issues/show/2629
> It is a potential API change.


Nice info.
We'll judge only "Feature" tickets at the end of Mar.

If we figure out that some "Bug" tickets include spec change after
Mar., they will be rejected unless it is inevitable (e.g., SEGV is
caused by wrong API design).

So, please let us know such bug tickets now.
947c97a2c119e85989d2ca63135a5b5e?d=identicon&s=25 Roger Pack (Guest)
on 2010-03-23 19:10
(Received via mailing list)
> One ticket I would like to bring some attention to is 2152 (Float#to_s)

Another would be this issue:
http://redmine.ruby-lang.org/issues/show/2012 setting event_flags on
thread creation

Koichi could you take a look at that patch sometime? Or some other
submaintainer of thread.c could?

Another would be feature request 1961 (for __dir__)
http://redmine.ruby-lang.org/issues/show/1961
Thanks!
-rp
4feed660d3728526797edeb4f0467384?d=identicon&s=25 Bill Kelly (Guest)
on 2010-03-25 02:35
(Received via mailing list)
Yusuke ENDOH wrote:
>
> If we figure out that some "Bug" tickets include spec change after
> Mar., they will be rejected unless it is inevitable (e.g., SEGV is
> caused by wrong API design).
>
> So, please let us know such bug tickets now.

Hi,

I think some of the remaining unicode path issues on windows
can be addressed for 1.9.2.  I have uploaded a patch for
Dir.mkdir:

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


I will attempt File.stat next.



Regards,

Bill
947c97a2c119e85989d2ca63135a5b5e?d=identicon&s=25 Roger Pack (Guest)
on 2010-03-25 10:11
(Received via mailing list)
>> Koichi could you take a look at that patch sometime? Or some other
>> submaintainer of thread.c could?
>
> Sorry for my late response.  That patch seems good.  If there is no test
> regression, I agree to apply it.

Much thanks.
-rp
4feed660d3728526797edeb4f0467384?d=identicon&s=25 Bill Kelly (Guest)
on 2010-03-25 11:27
(Received via mailing list)
Bill Kelly wrote:
>
> I think some of the remaining unicode path issues on windows
> can be addressed for 1.9.2.  I have uploaded a patch for
> Dir.mkdir:
>
> http://redmine.ruby-lang.org/issues/show/1685
>
>
> I will attempt File.stat next.

Sorry, I was not aware of win32-unicode-test branch.  It appears
to be mostly complete, and cleanly implemented.

I see in http://redmine.ruby-lang.org/issues/show/2026
that U.Nakamura said:

  You can see what we are doing about Windows' Unicode path name
  support on win32-unicode-test branch.

  The results of the branch will be merged to trunk before 1.9.2
  feature freeze.


Is there a reason the code should not be merged?


Regards,

Bill
86c07aa43c6df798df005edd84ee8b56?d=identicon&s=25 Marc-Andre Lafortune (Guest)
on 2010-03-26 18:55
(Received via mailing list)
Hi,

I have been travelling and otherwise quite busy recently, so I have
been accumulating some feature requests I didn't get the time to post.
I will do so today.

Please excuse the fact that it is a bit last minute.

Hopefully some of them are simple and compelling enough that we can
agree on the specs in time for feature freeze.

Thanks.

Marc-Andr
This topic is locked and can not be replied to.