[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Tagging kdesupport projects
From:       Harri Porten <porten () froglogic ! com>
Date:       2008-09-01 12:15:42
Message-ID: Pine.LNX.4.64.0809011410010.20876 () pudel ! froglogic ! com
[Download RAW message or body]


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.

[prev in list] [next in list] [prev in thread] [next in thread]