On Thursday December 6 2012, [email protected] wrote: > > On Monday December 3 2012, Knoll Lars wrote: > > > Dev: > > > > > > Dev is the branch where you can land anything that's supposed to go > > > into 5.1. The following policies apply: > > > > > > * Changes have to be source and binary compatible > > > * You can add new method and classes given that they are fully > > > documented and tested * Please do not add half finished features. > > > Create your own branch for that, and only push your changes once the > > > > feature is fully done. > > > > Should we add: > > > > * carries a change to dist/changes-5.1.0 if it's (Qt-)user-visible (bug > > fixes, > > new features, performance fixes)? > > > > Same for stable once 5.0.0 branches off? > > This would cause many more staging conflicts, as most changes would touch > the same file.
If we're successful, this will be a non-issue once a few dozen entries have been added (unless everyone tries to append instead of inserting entries in some sorted order). > I'd suggest that bug fixes should not touch the changes > file, only new features. That would be a change from previous practice (changes-4.8.x, say; I've understood changes-5.0.0 to be a one-time glitch), which probably didn't include all, but at least some bug fixes. Thanks, Marc -- Marc Mutz <[email protected]> | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
