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