backwards compatibility & how namespacing might help or not

[Albert Astals Cid]

El Dilluns, 26 de gener de 2015, a les 17:22:49, Harald Sitter va escriure:
> 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.

Yeah, i don't think that what you suggest really helps much, otherwise you'd 
end up with two kglobalaccels running at the same time, which is probably a 
very bad thing.

So yes, a better way of moving thing arounds is needed, or maybe we just need 
the dust to settle a bit so that we realize where each thing really belongs 
and it'll hopefully fix itself?

Cheers,
  Albert

> 
> 
> 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 at kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel