Ruby-core met twice last week in Japan to discuss the future plans for releasemanagement and backport maintenance of Ruby.

Season's greetings everyone!

You can watch the recording from Thursday's meeting onustream, thanks to@mrkn for the recording!

Although we didn't have a video recording from the meeting on Friday, werecorded our skype conference and is available onsoundcloud. Thanksto @sora_h for the recording and moderating skype!

Below I have summarized the meetings for each day and organized them intoagenda items. Each agenda item should have an associated ticket on our bugtracker that you can follow for more information.I will be updating these tickets with our conclusion shortly!


Last Thursday several ruby-core committers, including Matz, met to discuss thefuture of Ruby. Here's the summary by topic:

2.1.0 Release Schedule

Version 27 on bug tracker

  • We will see RC1 this week (2013-12-8 - 2013-12-14)
  • RC2 is only necessary should a major issue be found on RC1
  • A new branch will be created, and code freeze will be activated
  • All bug fixes must be approved by the release manager (@nalsh)
  • 2.1.0 will be released on christmas 2013 (2013-12-25)

2.1.0 Maintainer

misc. #9215

  • Undecided
  • @nalsh will maintain 2.1.0 for 2 months after release

Semantic Versioning

misc. #8835

Translations of this discussion are available here:

To summarize:

  • We accept proposal of @hsbt
  • The following proposal will begin with 2.1.0

Version Schema `ruby-{MAJOR}.{MINOR}.{TEENY}`

  • `MAJOR`: increased when incompatible change which can't be released in MINOR
  • "MAJOR is for party", reserved for special events
  • `MINOR`: increased every christmas, may be API incompatible
  • `TEENY`: security or bug fix which maintains API compatibility
  • `PATCH`: number of commits since last MINOR release (will be reset at 0 when releasing MINOR)

`TEENY` may be increased more than 10 (such as `2.1.11`), and will be releasedevery 2-3 months.

Matz and other attendees were concerned about `TEENY >= 10`.


We will maintain the following branches:

  • trunk
  • `ruby_{MAJOR}_{MINOR}`
  • `ruby_{MAJOR}_{MINOR}` across `TEENY` releases
  • tags will be used for each release

API Compatibility

  • Removing API is an incompatible change
  • such as (`STDIO_READ_DATA_PENDING`, etc.) must wait for 2.2.0
  • an incompatible change must increase `MINOR`

ABI Compatibility

  • Scheme of `{MAJOR}.{MINOR}.0`
  • Keep ABI compatibility with same `MINOR` release, so `TEENY` is fixed at 0
  • Retain compatibility across `TEENY` releases

We are concerned with changes required for existing tools, such as:

  • svn
  • backport / merger


We need to announce our plans for removing patch level semantics, in order touse `{MAJOR}.{MINOR}.{TEENY}`.

Maintenance Policy for 1.8.7 and 1.9.2

misc. #9216

1.8.7 and 1.9.2 will be supported for security fixes until June 2014.

  • @hone02 and @_zzak will assume maintainership
  • After the 6 month maintenance period, we can add more committers to extend another 6 months.

In the past we have supported vendors who wish to maintain legacy versions. In2009 the maintenance of Ruby `1.8.6` was transferred to Engine Yard when theyreleased `1.8.6-p369`.

We were given permission from Matz to release backport versions of Ruby forsecurity fixes.

  • It should be up to the maintainer
  • Security releases only, even after EOL

We made an important decision on this policy on Friday, please read the summaryfor that day in the next major section.

Maintenance Policy for 1.9.3

misc. #9217

  • 1.9.3 maintenance is commissioned by the Ruby Association
  • It will receive security fixes until March 2014
  • Additional 3 month security maintenance period may be supported by @unak

Maintenance Policy for Future Versions of Ruby

misc. #9215

  • 2.0.0 will received normal maintenance until February 2014 and 1 year of security maintenance
  • Each MINOR release starting with 2.1.0 will receive 2 years normal maintenance and 3 years security support

We want to encourage a more routine process to improve user expectation andexperience.

It's encouraged that each release manager decide on a roadmap for theirversion, although an absolute schedule and maintenance plan is difficult.

Policy Announcements

misc. #9219

The following pdf describesthe current maintenance plan for all versions. Thank you@mrkn for creating this document!

We will offer a conclusive policy document for all versions during the announceof the 2.1.0 release.

I will publish this document shortly!

Maintainer Appointment and Discharge

misc. #9218

We would like to develop a process for adding or removing branch maintainers,in order to prevent sudden death of branches.

Should a maintainer become inactive, we can rely on the following procedures:

  • nobu can help as global maintainer (patch monster)
  • any committer is responsible for contributing to priority maintenance (such as security)
  • we will decide the next maintainer during discussion on mailing list, and request their assignment

Anyone can replace the role of release manager, should they become inactive.

Every issue can escalate to Matz, should he become inactive maybe we need toreplace Matz.. (we should fire Matz!)

Asking to declare an expected maintenance period during appointment was rejected, see below:

@nagachika, current maintainer of `2.0.0` madethe following comment:

I never publish maintenance period for 2.0.0. I thought I can maintain it
for 2 years in "normal maintenance mode" and then turn into "security only
maintenance mode".
Now I feel a little hard to keep current pace of activity for maintenance
for 2.0.0.

It was suggested that @unak may begin maintenance of2.0.0 in March 2014.

GC Merits and Documentation

misc. #8962

I requested Matz order Koichi-kun to write a document for extension authors, heapproved for the following reasons:

  • Extension authors need a guide to implement Write Barrier
  • Writing extensions using WB is difficult
  • (nobu's children screaming loudly on skype)

However, encouraging the use of WB will cause serious problems. So Koichi willguide them to write extensions without using WB.

Since we only implement WB internally, an advanced extension author shouldrefer to the internal implementation of WB usage. Such examples could be Array,more details on this will follow in the development of this documentation.

Koichi adds, "its ok to be shady".

I will help with authoring this document.

Error Hiding

Feature #7688

We discussed this ticket, and concluded the following statements:

  • The current status has improved in many cases, but it's not perfect
  • Matz is undecided on the best way to improve performance
  • Okay to experiment after 2.1.0 is released

Various other discussion and events during Thursday

After watching the video I wrote a roughsummary, since most of thediscussion was in English. The following other events took place during themeeting:


On Friday, several committers met to discuss the events that took place duringthe previous meeting. We made important decisions on the maintenance policy forbackport versions and commercial support.

Branch Schema for Semantic Versioning `ruby_MAJOR_MINOR`

misc. #8835

We discussed a concern with handling security releases given the proposed branching schema.

During the 1.8 series we had a dedicated ruby_1_8 branch with no `TEENY`version in the name. In this time we had to release a security fix from thisbranch, however there were existing unreleased bug fix patches on this branchcausing a regression.

The previous solution was to create a new branch (`ruby_1_8_6`) and beginmaintaining two branches for the 1.8 series.

  • Additional branches may be added to support cherry-picking of security fixes.

We are concerned because security versions may occur more frequently betweenMINOR branch changes.


After reviewing the discussion from the previous meeting we discussed theconcern of `TEENY >= 10`.

  • String comparison bugs exist, such as: `"2.2.2" <= "2.2.10" #=> false`
  • We can fix this by abandoning strings
  • The version number can be anything that acts like String
  • We will postpone this situation

Tooling support

Most maintainers use tools from trunk, so they need to remain compatible withbackport branches. Any change in this policy should be documented.

Maintenance Policy for 1.8.7 and 1.9.2

misc. #9216

As discussed, we will commit security patches for 1.8.7 and 1.9.2 until June2014, however one major decision change was made to this policy:

Reason being, we don't want any new tickets, as an official release will resultin continue responsibility of ruby-core to follow up on maintenance. Our teamresources are already low, and we want to encourage upgrades, not supportoutdated versions.

  • If someone requests a release for 1.9.2 we can help them.

We need to write documentation for upgrading to supported versions, this isstrongly needed regardless of any policy changes.

Maintenance Policy for 1.9.3

misc. #9217

We strongly agree on one major point:

  • An official announcement on this issue is critical

Maintenance Policy for Future Versions of Ruby

misc. #9215

We had an extended conversation about the maintenance policy of all Rubyversions.


  • Security fixes become priority
  • Its maintainer's decision for priority of bug fix and security fix


We decided the following conclusion:

  • 3 years supported for MINOR versions as a team
  • Maintenance is not contractually obligated, but a "best effort"
  • Should a branch become toxic, we will EOL within reasonable time (6-8 months).
  • A shortened EOL is determined based on maintainer activity and team decision
  • The branch maintainer is not committed to the entire 3 year period
  • It's the responsibility of ruby-core as a team to support the version in life cycle

It's important to note: its a team responsibility to maintain a version ofRuby, and maintenance for more than 2 versions is difficult.

Our maintenance period should be:

  • A minimum of 6 months, and at best 3 years.

Our goal is to avoid a sudden death.

On commercial support

@ayumin offered the following statement:

Ruby-core doesn't need to maintain old branches, the important point is
announcing when we decide to give up on branches.

We should specifically define the organization responsible for maintaining aversion. Whether its ruby-core, vendor, or commercial organization, isunimportant.

It's the responsibility of the business party involved to maintain backwardscompatibility, not ruby-core.

We should encourage commercial support for EOL rubies, such documentation wouldbe beneficial.


That about wraps up the summary of both meetings, thank you to everyone who could attend!

Thanks for everyone who helped make this meeting possible, especially:

  • Cookpad for hosting both meetings on short notice
  • @sora_h for moderating irc, skype, and creating the audio recordings
  • @mrkn for the video recording on Thursday
  • @lchin for translation support on Friday
  • Everyone who attended and helped discuss the future of Ruby