From: "NARUSE, Yui" <naruse@...>
Date: 2011-08-23T20:20:01+09:00
Subject: [ruby-core:39056] Re: [Ruby 1.9 - Feature #5056] About 1.9 EOL

(2011/08/23 20:09), Lucas Nussbaum wrote:
> 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?

You don't want patch release?

-- 
NARUSE, Yui  <naruse@airemix.jp>