[ruby-core:39060] Re: [Ruby 1.9 - Feature #5056] About 1.9 EOL

On 23/08/11 at 20:20 +0900, NARUSE, Yui wrote:
> (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?

It depends on your definition of 'patch releases'.

'patch releases' could be 'bugfixes-only' releases, such as the Linux
2.6.32.x releases, the GNOME stable releases, the Debian 'point
releases', etc.

Currently, Ruby's definition of patch releases is a bit unclear to me:
it contains bugfixes, but also new features, and sometimes
regressions. You can't say for sure that 1.9.2p290 is better in all
aspects than 1.9.2p180, because so many things have changed that it's
unlikely that no regressions have been introduced.

So, in 'my' ideal world, we could get something like:
- every 6 months, a new release of Ruby, with some bugfixes, some new
  features, some regressions ;). This release is branched/tagged from
  the main development branch of Ruby (this ensures that no code stays
  in trunk for too long, without users).
- maybe, patch releases, which are for users who require a "rock-solid",
  absolutely stable Ruby. Those releases would only contain bugfixes.

You wouldn't need to do patch releases for every Ruby releases. You
could adopt a "long term support" model, where some selected Ruby
releases will be maintained for a long time.

 Lucas