On Fri, 27 Jan 2012 23:07:07 ext Olivier Goffart wrote: > On Friday 27 January 2012 09:09:46 Kent Hansen wrote: > [...] > > > If there is no quick fix, the last resort is to "pin" one or > > more of the dependencies' to a particular SHA1 (e.g. from the qt5.git > > submodule) in the sync.profile until the issue has been resolved, then > > "unpin" it again later. > > Why is that the "last resort"? > This seems totally normal and was the whole point of modularisation: > Differents modules can be developped at different speed.
It's the last resort because proper modularization isn't going to cause these sorts of problems. Proper modularization means that you aren't going to screw up dependent modules unless you make deliberately incompatible changes to your API, for which you normally will provide a smooth transition path (e.g. deprecate the old one and let them live side by side for a while). So these shouldn't happen, and your first step should be to fix your smooth transition path to be smooth enough for CI not to be blocked. Because CI blocking would mean that users of your module have just had their code broken by a module below. We don't like putting them in that situation. That said, stuff exists like QtDeclarative reaching deep into the private headers of QtCore, and depending on details of the metatype system. So we're largely suffering because we have not been able to modularize properly. > If not, modularisation was just a waste of time and a way to make > development more difficult. Arguably we have not successfully modularized if we still have such tight dependencies. But I'm optimistic enough to think it will settle down once 5.0.0 is out and we're vaguely respecting compatibility again :) . -- Alan Alpert Senior Engineer Nokia, Qt Development Frameworks _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
