A Dilluns, 19 de setembre de 2011, Sebastian Trüg vàreu escriure: > On 09/19/2011 11:07 AM, Albert Astals Cid wrote: > > A Dissabte, 17 de setembre de 2011, Sebastian Trüg vàreu escriure: > >> On 09/17/2011 04:30 PM, Albert Astals Cid wrote: > >>> A Dissabte, 17 de setembre de 2011, Sebastian Trüg vàreu escriure: > >>>> On 09/16/2011 11:46 AM, Albert Astals Cid wrote: > >>>>> A Dijous, 15 de setembre de 2011, Sebastian Trüg vàreu escriure: > >>>>>> With the currently ongoing split of kdelibs and kde-runtime > >>>>>> according > >>>>>> to > >>>>>> KDE 5.0 frameworks Nepomuk has already partly been > >>>>>> reorganized: > >>>>>> > >>>>>> kdelibs/nepomuk and most parts of kde-runtime/nepomuk have > >>>>>> been > >>>>>> moved > >>>>>> into the new repository "nepomuk-core". kdelibs master has > >>>>>> already > >>>>>> been > >>>>>> frozen for some time. kde-runtime/nepomuk master is now > >>>>>> effectively > >>>>>> frozen as development has moved to the new nepomuk-core > >>>>>> repository. > >>>>>> > >>>>>> Shortly new repositories as outlined in [1] will be created to > >>>>>> contain > >>>>>> the rest of kde-runtime/nepomuk. > >>>>> > >>>>> This is suboptimal regarding translations since now we have 2 > >>>>> different > >>>>> repositories that want to create a translation template with the > >>>>> same > >>>>> name. Please comment out or remove the Messages.sh file from > >>>>> kde-runtime/nepomuk > >>>> > >>>> damn, I always forget the translations. Very sorry about that. > >>>> > >>>> Now what is the solution. To be honest I am very confused about > >>>> the > >>>> 4.8 > >>>> release. kdelibs master is frozen. kde-runtime master apparently > >>>> should > >>>> be frozen but is not. > >>> > >>> There is no reason kde-runtime master should be frozen. kde-runtime > >>> master will be part of the 4.8 release and has to compile against > >>> kdelibs 4.7> > >>> > >>>> There will be no changed in kdelibs for 4.8 but > >>>> Nepomuk needs them (well, we could do them as bugfixes in 4.7 > >>>> also). > >>> > >>> Not sure I understand the sentence so won't answer. > >>> > >>>> Then what about kde-runtime master? Should we continue to work in > >>>> there > >>>> until 4.8? If so, I would disable translations on nepomuk-core and > >>>> only > >>>> enable them for 5.0. > >>> > >>> If all those nepomuk-* repositories depend on frameworks, they can > >>> only > >>> be released with 5.0, so yes, we should disable translations there. > >>> If > >>> all those nepomuk-* repositories do not depend on frameworks and > >>> will > >>> be released with 4.8 (you shall inform the release team about it > >>> since > >>> there is yet another tarball to release) then you need to clean > >>> kde-runtime because otherwise we will be shipping duplicate code. > >> > >> since I really do not want to maintain two branches I propose removing > >> nepomuk from kde-runtime master completely. > >> However, since nepomuk-core also contains all the nepomuk libs which > >> are > >> now in kdelibs 4.7 we need to act here, too. > >> I propose that we move to include path nepomuk2. The main library is > >> already called nepomukcore. I am not sure about that yet. So maybe it > >> could be renamed to libnepomuk2 also. > >> That way we would have the libnepomuk from 4.7 and the new stuff from > >> libnepomuk2 and the only thing we need to ensure is that the 4.7 libs > >> still work with the services from nepomuk-core. Applications are then > >> advised to already depend on nepomuk-core instead of kdelibs. > >> > >> Opinions? > > > > Not sure I understand the mail, but to me it seems you are proposing > > breaking binary compatibility between 4.7 and 4.8 releases and killing > > of code and renaming of libraries. > > > > If that is what you propose, it is a big no go for me. > > no, I am proposing to remove runtime components from kde-runtime and > using those from nepomuk-core instead. kdelibs will not be touched (frozen). > As discussed on IRC we could also make the libs in nepomuk-core private for > now (until frameworks) and only treat it as a split from kde-runtime.
That sounds fine to me, installing the new libs (with different names to not clash with kdelibs 4.7) seems fine too. I was just concerned with duplicated binaries and API breaks, if there is none, i don't see why you should not go ahead :-) Albert > > Cheers, > Sebastian
