[Development] RFC: What constitutes a "non-destabilising" bug-fix?

[Olivier Goffart]

On Friday 11 January 2013 07:40:39 Thiago Macieira wrote:
> On sexta-feira, 11 de janeiro de 2013 15.21.43, Olivier Goffart wrote:
> > Go to stable:
> >   a. Fixes to regressions against a previous "recent" version of Qt. (less
> >       than 2 or 3 years old)
> >   b. Fixes in new feature introduced in the most recent minor version.
> >   c. Critical fixes (P1/P0): security, crashes or data corruption.
> >   d. Compilation fixes or adaptations required for different version of
> >       the compilers or upstream libraries.
> > 
> > Everything else go to dev.
> 
> I agree with almost all: I'd like to relax "c" to include Important (P2)
> fixes, subject to the approvers' decision. Those should happen most
> commonly in the first one or two patch releases (.0 and .1).

Everything is already subject to approvers' decision.  So specifying it is 
redundant.

I think anyway every rules rules should tollerate exceptions. In certain cases 
approvers will break those rules for good reason.
Example: a one-line feature that is critical for an important application may 
get in in a patch release.

The reason why I would avoid non-regressions P2 fixes in the stable branch is 
that they are more risky than the others one.

A new minor version gets much more QA that a patch release. (there are beta 
release).  Also, everybody tollerates a x.y.0 to have bug, but it is really 
bad if we introduce more bugs in patch release.
And I beleive one good way to avoid regressions in patch releases is to limit 
the amount of risky changes that goes it.

If we tollerates P2, i'm afraid every P2 goes in, and that's most of the fixes.

Do you still think the wording should include P2?

-- 
Olivier

Woboq - Qt services and support - http://woboq.com