[Development] Coin news

Oswald Buddenhagen oswald.buddenhagen at qt.io
Wed Oct 26 11:28:28 CEST 2016


On Wed, Oct 26, 2016 at 08:47:48AM +0200, Marc Mutz wrote:
> On Tuesday 25 October 2016 10:55:34 Oswald Buddenhagen wrote:
> > On Tue, Oct 25, 2016 at 07:22:41AM +0000, Jędrzej Nowacki wrote:
> > > I would like to also remind everyone, that intermodule API changes need
> > > to be merged in two steps. For example if you plan to change a method
> > > "void foo()" in qtbase to "void foo(const QString&)", that would be the
> > > right order of execution: 1. Commit a change to qtbase that _adds_ 
> > > foo(const QString&)
> > 
> > 1a. wait for qt5 integration. 2 would not integrate in the submodules
> > without 1 being in qt5 already.
> > 
> > > 2. Update all modules that use foo() to use foo(const QString&)
> > > 3. Wait until Qt5(dev branch) submodule update, that gathers changes from
> > > 1 and 2
> > 
> > only 2 at this point.
> > 
> > > 4. Remove old foo() from qtbase
> > 
> > 4a. wait again until the final qt5 integration to see it in packages.
> > 
> > so six steps in total. and it takes exactly as long as it sounds.
> > 
> > > If you do not follow we would have to revert your changes.
> 
> Alternatively, #define a macro in the upstream module when adding the new API, 
> and check for it in the downstream module to decide which API to use. These 
> two changes can then proceed independently, followed at any time after just 
> one qt5.git integration by two clean-up commits.
> 
that's indeed better in the optimal case:
1. prepare downstream module and update upstream module
2. have them integrated into qt5. make sure that the upstream update
   does not go in before the downstream adjustment (you can generally
   assume an atomic integration).
3. clean up both modules
4. have them integrated into qt5. make sure the upstream cleanup does
   not go in before the downstream cleanup.

another good thing about this variant is that you can atomically fix
issues introduced due to signal/slot overloading, which you'd otherwise
have to do separately in advance, introducing yet another two-stage
integration.

a downside is that the history is messier, because there are inherently
at least two commits in every downstream module. and it may get even
more messy if you notice later in the process that you need to adjust
the downstreams further before the qt5 integration succeeds. that's
because the downstream integrations are basically dummies and you don't
notice that something went wrong until the qt5 integration which pulls
in the upstream change.

> Thanks,
> Marc
> 
> -- 
> Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
> Tel: +49-30-521325470
> KDAB - The Qt, C++ and OpenGL Experts
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development



More information about the Development mailing list