On 23/08/11 at 06:50 +0900, SASADA Koichi wrote: > (2011/08/10 7:18), Yukihiro Matsumoto wrote: > > My opinion is that we should make 1_9 branch after release of 1.9.3. > > Then we will move forward 2.0 works on the trunk. 2.0 works includes > > > > * keyword argument support for method definitions > > * Module#mix > > * Module#prepend > > * and others (refinement, classbox, or method shelter?) > > > > Currently I don't plan no big change to C API, but Ko1 might have > > different opinion, especially regarding MVM. > > I think I need to give up the API (and more about data structure) > changes. It should be done at 3.0 or later if there is no time/no > person to consider. > > And I want to propose the followings: > > - Release Ruby 2.0 with new features. > - Release Ruby 1.9.4 with performance changes and bug fixes. > > Advantage: > - We can concentrate on implementing new features on 2.0 > and also can concentrate on improving quality on 1.9.4. > - If the discussion of new features are not closing, > we can release 1.9.4 (I think it is most important (*1)). > > Disadvantage: > - It is ambiguous that which branch we should apply bug fixes. Hi, While I am not a Ruby developer (I only do "indirect" work by working on Debian packaging), I have been involved in a large number of Free Software projects over the years, and know a fair bit about release management. I think that the current way of managing branches and releases of Ruby is not optimal. There are too many (active) branches: the ruby_1_8, ruby_1_8_6, ruby_1_8_7, ruby_1_9_1, ruby_1_9_2, ruby_1_9_3 and trunk branches all received commits during the last year. That causes several problems: - developer manpower is split between those branches. - it is hard to keep track of bugfixes between branches. A severe bug affecting ruby_1_9_* is likely to require a fix in ruby_1_9_2, ruby_1_9_3, and trunk. Sometimes bugfixes don't get backported everywhere, resulting in releases with open bugs. The release cycles are too long, leading to: - "time-to-market" for new features that is likely to be demotivating for developers - long stabilization periods (+ unclear release schedules) The current situation looks a lot like what was happening in the end of the Linux 2.4 era, where most development was happening in the 2.5 branch. I think that you should inspire from the release management of Linux 2.6, and use one-branch-per-feature rather than one-branch-per-release. Then, you could have a single integration branch (that would most likely be trunk), and make releases from this branch, since features will have time to mature a bit inside feature branches. Using shorter release schedules would also probably help. The addition of new features will be more incremental (less new features per release), which will also reduce the stabilization periods. Several important projects now use a 6-month release cycle. Maybe that could work for Ruby too? Lucas