Binary incompatible changes

[David Faure]

On Friday 28 February 2014 20:49:34 Ben Cooksley wrote:
> I suggest that any further BC or SC changes be rolled out more
> carefully, with pushes being separated by sufficient time for the CI
> system to complete builds of earlier modules.

I just tried to do that, with the KF5 version number increase, which also breaks if pushed to all modules at the same time.
(since it changes both "this is my version" and "this is the version I need in my dependencies").

Here's my current solution - it starts nicely, with tier1 and then tier2.... but then...
(thanks Aurélien for the diagram, this would be impossible to do otherwise!)

     cd kdesupport/attica ; git push
     for f in `grep -l tier:\ 1 */*yaml`; do (cd `dirname $f` ; git push); done
     (wait for CI)
     for f in `grep -l tier:\ 2 */*yaml`; do (cd `dirname $f` ; git push); done
     (wait for CI)
     for d in kconfigwidgets kservice kpty kjsembed kunitconversion; do (cd $d ; git push) ; done
     (wait for CI)
     kiconthemes kdesu
     (wait for CI)
     ktextwidgets
     (wait for CI)
     kxmlgui
     (wait for CI)
     kcmutils kbookmarks
     (wait for CI)
     kio 
     (wait for CI)
     kinit kparts kdeclarative knewstuff knotifyconfig kfileaudiopreview
     (wait for CI)
     kactivities kmediaplayer kross kdewebkit khtml
     (wait for CI)
     plasma-framework kdesignerplugin frameworkintegration kde4support
     (wait for CI)
     krunner
     (wait for CI)

Done!

So, in reality we have 12 tiers :-)

So yeah, it's doable, but quite painful. I wish we could script this, but "wait for CI" is hard to script...
But at least we could have "tier 3.1", "tier 3.2" etc. so we can push in layers with the layer information
inside the repo instead of in this mail (or a hypothetical script that cannot really be automated).

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5