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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
