backwards compatibility & how namespacing might help or not

[šumski]

On Monday 26 of January 2015 17:22:49 Harald Sitter wrote:
> 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?
(not direct solution for the 'principle' of question, but at least in this 
case, we've had kglobalaccel5 daemon in a separate subpackage of the plasma-
workspace source on openSUSE, precisely as it was hinted already some time ago 
the merge might happen. we did the same with drkonqi.)

Cheers,
Hrvoje
> HS
> _______________________________________________
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20150126/70da8e11/attachment.sig>