[Nepomuk] Nepomuk code moved to nepomuk-core

[Albert Astals Cid]

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