From: Lucas Nussbaum <lucas@...>
Date: 2011-08-24T23:28:23+09:00
Subject: [ruby-core:39086] Re: [Ruby 1.9 - Feature #5056] About 1.9 EOL

On 24/08/11 at 23:03 +0900, Yugui wrote:
> On Tue, Aug 23, 2011 at 9:20 PM, Lucas Nussbaum
> <lucas@lucas-nussbaum.net> wrote:
> > Currently, Ruby's definition of patch releases is a bit unclear to me:
> > it contains bugfixes, but also new features, and sometimes
> > regressions.
> 
> I'm trying to reject new features for patch releases.  Could you give
> me an example of my mistake?

We migrated from svn to git for Debian packaging and did not keep the
history, so it's a bit hard to find exact references.

Looking at the recent history, 1.9.2 has been good in that regard, with
the exception of the fix for CVE-2011-0188 that is missing in .290,
which we had to backport from another branch (fix is r30993).
But that's not a good example, since it illustrates "hard to backport
every relevant bugfix", not "patch releases containing new features".

However, in the 1.8.7 branch, several patch releases were containing
user-visible changes that were not bugfixes, leading to
incompatibilities (I think it was in .72, but I'm not sure anymore). If
the policy is to not do that anymore, I'm very happy. :)

> Also I'm trying to keep patch releases without regression.  I know I
> did some mistakes in this area, but also I don't think your proposal
> prevents these kinds of mistakes.

I don't know if it's the case in Ruby, but there are projects where
there is some pressure from developers on release managers to push
features to users. A shorter release cycle helps in that regard by
making developers who want to push features to users happier.

  Lucas