Tagging kdesupport projects

[Matthias Kretz]

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.

If you don't know and don't want to care just do
  cd kdesupport
  svn up
  makeobj -jX install
whenever you do a full update or you see a compile error related to kdesupport 
libs. That's how I always understood kdesupport was supposed to work - and I 
never had problems with 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.

Yes, sorry. The Phonon version check is still not implemented. :(

> * In the intermediate phase develop the KDE code in a development branch

I'm sick of the svn branches mess I already did. No more if that if at all 
possible.

> * 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.

I favor Phonon development inside kdelibs, too. But it confused too many 
people. Now it still confuses some, but less so.

Still phonon is KDE code and a normal KDE project like everything else in 
kdelibs.

I probably confused some people by telling that I wanted you to rather use the 
Phonon 4.2 branch instead of Phonon trunk in kdesupport with KDE 4.1... Sorry 
for that but Phonon also needs testers before it gets released. :-P

I also disagree that I need to do a new Phonon release for every little change 
I do in libphonon and use in kdebase (or somewhere else). That's asking me to 
quit working.

If you want that requirement on kdesupport I want phonon moved out of it into 
it's own module so that it isn't called "outside of KDE" anymore but "part of 
KDE".

-- 
________________________________________________________
Matthias Kretz (Germany)                            <><
http://Vir.homelinux.org/
MatthiasKretz at gmx.net, kretz at kde.org,
Matthias.Kretz at urz.uni-heidelberg.de