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
_______________________________________________
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel
