1  mput's diary - 2006-12-04

This entry is rough translation of mput's diary - 2006-12-04. 'I' on this document is 'mput', who is a maintainer of ruby_1_8_5 branch. Please gime me a comment when you find anything wrong.

2  What happened on Ruby

Short Summary: Maintenance branch based on ruby 1.8.5 was created after many twists and turns. Bug fixes for 1.8.5 will be under the branch. 1.8.5.2 has been released as a first release.

Details: Roughly to say, there were two branches on Ruby; trunk and the others. We planned to develop on trunk branch, and the others are for maintenance. But practically speaking, we developed on both of them. We've added new functionalities and major changes that affects backyard compatibility not only to trunk but also to maintenance-branches. We've left it as it was since there were few committers^*1 who annoyed about it.

Security vulnerability CVE-2006-5467 was reported on such situation. Just one-line patch was able to fix it, but it's difficult since ruby 1.8 branches had a lot of changes form 1.8.5 - it was released more than 10 months ago. It's heavy request for most of ruby users to version up just for bugfix. We discussed about this issue in ML begun from [ruby-dev:29726]. As a result, we fixed bug as like [ruby-dev:29751].

Few months before, some Rubyist come together and discussed in RubyConf with eating chocolate^*2. We've concerned that I'll take care of Maintenance branch. So I suggested on [ruby-dev:29767] to freeze ruby 1.8 that is not stable at all even if it's called Maintenance version. No new functions and major changes to 1.8, just bug fix and maintenance on it. Contrary to my expectation, there were not a few objections for this idea. As a result of discussion in ML, We continue to develop on ruby 1.8, and to create maintenance branch under 1.8.5.

On 1.8.5 branch, we were ready to release 1.8.5.1 that has fix of CVE-2006-5467 (tag exists on CVS repository). But new vulnerability was reported to security@ ML before we released it. Someone suggests that it's not good idea to release two different versions in such short term. So that we released 1.8.5.2 without 1.8.5.1.

3  Where Ruby goes

Now, we have at least three branches; trunk, ruby_1_8, ruby_1_8_5. These branches will coexist until some later date.

We might create four new branches from ruby_1_8; ruby_1_8_6, ruby_1_8_7, ruby_1_8_8 and ruby_1_8_9 (I'm not sure 1.8.9 really released or not). They (and ruby_1_8_5) will be disposed on some conditions: for example, ruby_1_8_N branch will be deleted when ruby_1_8_(N+2) will be created. By technical constraint^*3, we'll delete when we reached a branch 1.8.N.4999. Also we still don't have clear plan about whole ruby_1_8 trees after a branch ruby_1_8_9 created.

We plan to release Ruby version 1.9.1 from trunk branch at Xmas 2007. If there will be no paradigm shift, branch ruby_1_9 and ruby_1_9_1 will be created in similar fashion of 1.8.

I draw a picture of branch tree based on the policy I wrote above. By the policy (N+2) branch will be deleted, there are maximum 7 branches available at the same timing. 4 branches are on maintenance, trunk for development, and 2 are middle of them^*4.

We have several undecided things like this:

• Who will maintain new branches?
• When a branch will be created (ahead or after preview) ?
• How to hand over each branch-manager's responsibilities when a new branch created?

these topics are still under discussion.

---

*1 Since ruby 1.7 is enough stable, many ruby users used 1.7 even if it's unstable branch. It might make committers to do anything on trunk.
*2 I consumed for the most part of chocolate. Be careful to take chocolate in midnight, because it easily changes into your weight.
*3 It's very rare case. If we released 1.8.5.x every day, .4999 will be released at Aug 2020. 1.8.6 may be released until then.
*4 Maybe as you can read from my wrotes, I unconvinced STABLE branch by technical reason. On the other hand, I understood it should good for motive.