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,
on 2010-03-15 15:12
on 2010-03-15 18:23
> === 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
on 2010-03-15 19:40
I'd like to bring attention to: http://redmine.ruby-lang.org/issues/show/2629 It is a potential API change.
on 2010-03-17 15:10
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.
on 2010-03-23 19:10
> 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
on 2010-03-25 02:35
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
on 2010-03-25 10:11
>> 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
on 2010-03-25 11:27
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
on 2010-03-26 18:55
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
Please log in before posting. Registration is free and takes only a minute.
Existing account
(Switch to SSL-encrypted connection)
NEW: Do you have a Google/GoogleMail or Yahoo account? No registration required!
Log in with Google account | Log in with Yahoo account
Log in with Google account | Log in with Yahoo account
No account? Register here.