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