From kde-core-devel Wed Apr 11 19:55:40 2007 From: Sebastian =?utf-8?q?Tr=C3=BCg?= Date: Wed, 11 Apr 2007 19:55:40 +0000 To: kde-core-devel Subject: Re: FW: [REMINDER] Upcoming KDE 4.0 Milestones + Nepomuk Message-Id: <200704112155.40739.strueg () mandriva ! com> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=117632117616237 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.