>> I'm trying to reject new features for patch releases. =A0Could 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. :)

Hi

I who linux kernel developer would like to explain this. In fact, Linux
has several stable branch maintainer and they have slightly different
maintenance policy. Similar, Ruby 1.8.7 and 1.9.2 have slightly different
policy. If you want and will become a branch maintainer of our community,
you may be able to have more different policy. That's authority and
responsibility
of a maintainer.

Anyway 1.8.7 is a really special exception, it's a final release of 1.8.x.
I don't think it's good example for discussing maintenance policy.