FW: [REMINDER] Upcoming KDE 4.0 Milestones + Nepomuk

[Sebastian Trüg]

If indeed we would have the possibility to break binary comp or even source 
comp in 4.1 I would vote for an inclusion now. I agree with Aaron that it 
would push application devels to use it. Me being one of them (the app 
devels) I know that using stuff in the kdelibs comes much easier than 
anything else.

Cheers,
Sebastian

On Wednesday 11 April 2007 20:58:09 Aaron J. Seigo wrote:
> On Wednesday 11 April 2007, Dirk Mueller wrote:
> > On Tuesday, 10. April 2007, Aaron J. Seigo wrote:
> > > > I'll take a look on this in the next two weeks but it would be nice
> > > > to make it optional until 4.1.
> > >
> > > this would realistically mean application integration in 4.2 or later.
> >
> > No. There can be applications making use of nepomuk by 4.1, and then we
> > can include a polished and tested version of it in kdelibs for 4.1.
>
> you really think that will happen if nepomuk isn't commonly available? one
> of two things will happen:
>
> - apps will use nepomuk in meaningful ways (e.g. perhaps amarok would use
> it for its metadata db) and everyone will install it -anyways- meaning that
> we haven't actually gained anything for the user base at all, except to
> require one extra piece of software to be installed
>
> - apps won't use nepomuk and nobody will actually install it.
>
> looking at how the realistic adoption of features in kdelibs tends to
> happen, applications tend to lag 1-2 versions behind what is both available
> and well known in kdelibs. many application developers, including those who
> write apps we ship with kde releases, do not develop against libs from
> trunk/. which means they first get access to features when a stable libs
> release happens.
>
> and then usually we have to do some awareness work to get people actually
> using it.
>
> > if we put nepomuik into kdelibs for KDE 4.0, then we have to stay
> > compatible with it (also binary compatibility).
>
> there is no reason we have to guarantee binary compat of new frameworks in
> 4.0. in fact, it may actually make sense -not- to do so for 4.0 so that we
> have the opportunity to get them right in 4.1 should we need to. kdecore,
> ui, kio, etc.. should remain BC, but the new stuff? i don't see a hard and
> fast reason why it must.
>
> > Just because its not in kdelibs doesn't mean applications can't make use
> > of it.
>
> my concern is not that they can't, but that they won't.
>
> > It just means its not part of 4.0. And thats great.
>
> great? no, it would suck. we can live with it, sure, but let's not pretend
> it would be some sort of success on our part.
>
> > Remember, there is
> > life after KDE 4.0 (at least if we ever manage to release 4.0 instead of
> > cramming every possible new feature in it (2nd version syndrome).
>
> erm ... i don't think that's what this is at all. this isn't asking for any
> extension of the release schedule. this is a library that has been a long
> time in the coming and expected for some time, not something brand new out
> of nowhere.
>
> heck, we already have apps using it now in svn so i can't see how it's 2nd
> version syndrome at all.
>
> i think there is lots of good prioritization happening with things being
> moved off to 4.1 on several fronts. that is indeed good. however, none of
> the points i raised as to why it would be a good idea to put nepomuk in
> kdelibs have been addressed.