[ANN] 1.9.2 release plan

#1

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,

#2

=== 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

#3

I’d like to bring attention to:
http://redmine.ruby-lang.org/issues/show/2629
It is a potential API change.

#4

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

#5

Hi,

2010/3/16 Hongli L. removed_email_address@domain.invalid:

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.

#6

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

#7

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

#8

Bill K. 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

#9

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