= Release Plan of 1.9 series
see also version independent topics.
(copied from , typo fixed)
Now Ruby 1.9.3 is much stable than on Feb. Its feature is getting
stable. It's time to decide a plan to release Ruby 1.9.3.
I propose the following rough schedule.
* The end of May: feature freeze. create ruby_1_9_3 branch.
* The end of Jun: implementation freeze. don't change without permission after that.
* The end of Jul or early Aug: release Ruby 1.9.3
The possible release blocker is the recent improvement of GVL. It is a
change in the core piece of Ruby and I would like to have it in Ruby
1.9.3 if possible.
I believe Kosaki-san is recently reviewing locks in YARV. Will it have
finished on the end of Jun?
(copied from )
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.