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