Tagging kdesupport projects

[Sebastian Trüg]

On Monday 01 September 2008 14:15:42 Harri Porten wrote:
> On Mon, 1 Sep 2008, Sebastian Trüg wrote:
> > Actually, no. At least I still do not get it. The way I understand it is
> > this: Whenever there is a KDE release, be it alpha, beta, or final, we
> > need a Soprano release as a dependency. So far this has always been the
> > case. KDE 4.0 uses Soprano 2.0 (but can also use 2.1 since its BC), 4.1
> > is based on Soprano 2.1 (currently 2.1.1 is the latest stable release,
> > check soprano.sf.net), and 4.2 will be based on Soprano 2.2 (currently
> > developed in trunk).
> > But I don't see why we need a release "just" to build trunk. Thrunk
> > changes all the time. I have no intention of building snapshots myself
> > all the time. I have no problem with an automated system for that though.
> > ;)
> > So, if you want to create a KDE release you will of course get a Soprano
> > release, too. But before that.... why?
>
> Because its a pain for all developers working on trunk. One never knows
> whether all of kdesupport needs to be updated and re-build too. And which
> branch to use for that.
>
> In order to not constantly break things for other developers a developer
> of non-KDE and KDE relying on it should
>
> * Version the non-KDE code in a way that it's clear to developers of KDE
> code that a requirement is not met.
>
> * In the intermediate phase develop the KDE code in a development branch
>
> * Or simply put all of it into the main KDE modules.
>
> I have to say that I find the tendency to move hard-requirement libraries
> (targetted at KDE mostly) into kdesupport a bit disturbing. It could have
> been done with KJS too (its only requirements are libstdc++, libstdc and
> pcre) but I found it counter-productive. Instead I favor development
> within KDE. Seperate packages for non-KDE use can always be produced.
>
> Harri.

I don't get the problem. It is so simple: on mondays it is possible that stuff 
breaks. thus, when it does, simply update kdesupport to trunk and keep on. 
You need to do the exact same thing with kdelibs. There are no multiple 
branches you need to choose from. There is trunk for bleeding edge developers 
and there are the releases in case you are an app developer who "only" needs 
KDE 4.0 or 4.1. There is absolutely nothing complicated about that. If you 
can compile kdelibs, you can also compile kdesupport, it is much smaller.

Sebastian