Handling of splitted Calligra repos and API changes

[Friedrich W. H. Kossebau]

Hi,

with KDb, KProperty and KReport, a few libs/frameworks have been already split 
off during the port of Calligra to Qt5/KF5.

And they pose a challenge that needs to be solved quickly:
traditionally we have had no ABI guarantuee in Calligra even in patch releases 
and of course also not during development. Because sourcecode of all libs and 
libconsumers were in a shared repo, and any API changes were done in atomic 
commits both to the libs and libconsumers (because by policy we require any 
commits to the repo to not break it's build).

With libs and libconsumers being split in separate repos the atomicity no 
longer is given.

Which results in problems:
* people might pull from repos missing part of API change commits
* current KDE CI triggered by commits will build repos without caring for
  dependencies between commits, using products from previous lib builds with
  old API for the build of libconsumer with commit using newer API
* ?

No idea how to solve the KDE CI one perfectly. But for the problem of pulling 
consistent states, what about the following rules with the split off lib 
repos: 
* no ABI breakage in patch releases for released branches
* weekday of API breakage: a set day per week development branches can get
  commits which involve API changes in the libs in separate repos
  still related commits should be pushed together in an as small timewindow
  as possible

No ABI breakage in patch releases might be a no-brainer, given that targetted 
3rd-party consumers would rely on that as well.
The second one would pick up something which seemed to work well enough in 
times where close kdelibs and kdeapps development was common, and where people 
also did separate svn "pulls" for libs and apps. Pushing related commits to 
all repos in small timewindows might not completely match atomic commits as 
possible with subversion. But in the end we all pull in time ("fetch latest 
commits now") and not by branch state ("fetch commits until xyz id"), so in 
practice this might work as well still.

What do you think? Would this work for you as well?

IMHO we need to have an agreed solution here before Kexi-frameworks is merged 
back, because it will force us into this situation (where Plan currently does 
not depend on KReport, my respective patch waiting since many weeks for 
someone to push this question for handling of the API-break challenge and to 
find an agreed resolution ;) ).

((While in the discussion this is only about those 3 libs for now... My 
personal desire is to make the Calligra document libs more accessible to other 
apps, which partially do document creating/processing. For that I would see 
some advantage to split off more libs into own repos as well. In the long run 
I would like to see Calligra move out of it's own corner and integrate more 
with the normal KDE application scene.
But more on that once we have finally passed the port hurdle, are back in 
normal feature development and can start talking post-3.0 (where 3.0 is now 
the first real release) :) ))

Cheers
Friedrich