backwards compatibility & how namespacing might help or not

[Harald Sitter]

ahoy ahoy

so...
kf5.7 will contain kglobalacceld5
plasma5.2 will also contain kglobalacceld5 if it was built with kf5.6

this poses a binary conflict which makes kf5.7 not a simple "drop-in"
replacement for kf5.6 without recompiling plasma, which effectively
makes this new construct just like the old construct (kde sc) but with
more repos :'<

problem:
this presents a compatibility problem as (for example) kubuntu
couldn't drop kf5.7 into an update of a released system without also
rebuilding plasma-workspace.
add on top of that the fact that plasma-workspace might do any
arbitrary amount of things when built against kf5.7 (disable features,
add features, explode, whatever) and it effectively disqualifies any
frameworks release after 5.6 being landed in a manner where one can
somewhat tightly control regression impact (at least to the
understanding of ubuntu on how to make the scope as small as
possible).
this is not the advertised compatibility :P

solution:
everything ever should be namespaced somehow. kglobalacceld5 should
have a kf5 suffix or prefix, headers should go into a kf5 directory,
cmake packages should have kf5 somewhere in their name etc. etc.

while discussing this on IRC the issue was raised that the artifacts
installed by a framework couldn't possibly be kept 100% conflict free
with the outside world. while that is of course true I propose that
rigorous namespacing on our side kicks the ball to whoever conflicts
with us and in general renders the likelihood rather small altogether.

there are of course various additional considerations to be made and
in particular when moving bits from plasma or even applications into
frameworks a proper backwards compatible transition path ought to be
worked out for each case specifically. so even with namespacing the
grey cells need some exercise for sure.


at the end of the day I suppose the question we need to answer is do
we want to strive for 100% compatibility or is a best-effort
compatibility good enough.

best-effort sure is cheaper, it does however also mean that I doubt at
least kubuntu will ever put frameworks releases into the regular
updates procedure, preventing a good chunk of users from getting these
releases. this is in of itself not a bad thing, but it does mean that
a third party developer who wishes to target for example Ubuntu will
have to jump through hoops to get the latest and greatest frameworks
to the user.

thoughts?

HS