kdesupport branch for 4.0.x

[Tom Albers]

At Tuesday 25 March 2008 16:27, you wrote:
> On Tuesday 25 March 2008, Tom Albers wrote:
> > To be able to ship 4.0 to the customers distro's /must/ have version
> > of all the dependencies of KDE4. Including the ones which live in
> > kdesupport. How else can they ship it?
> 
> I'm not seeing how this is relevant. If you want to develop or test a 
> development version, you'd like to use the latest available version. The 
> distro might ship a previous version of kdesupport apps, not the latest 
> stable one. Especially if you run the latest "official", supported 
> distro KDE and build yourself the latest development version (either 
> from trunk or stable). Being able to test easily with the latest 
> available version is good also for the project, as bugs will be caught 
> easier something got broken, not just when the distros will compile 
> their new packages on a new KDE release. 
> For example a distro releases with KDE 4.0 and Soprano 1.0. You 
> work/test the not-yet-released KDE 4.0.3, by building it from source. If 
> you use the distro packages, you will have to use Soprano 1.0, even if 
> Soprano 1.3 was already released. Or you have to download Soprano 1.3 
> and compile it. Now this extra download is fine for any 3rd party app, 
> but if we have a kdesupport module which contains some 3rd party apps, 
> why not make our life easier and provide this module not only for trunk, 
> but for the stable branch as well, containing the latest stable version 
> of the 4rd party apps?

You assume that someone will keep that kdesupport branch filled with up to date stuff, which I seriously doubt unless this branching is requested by /them/.

I don't see any difference with any other dependency though.  If you want the latest, chances are that your distro does not have it and you need to compile it yourself.  Either from a tarball or from svn. You never know untill someone communicates that.

I just don't see the need, if the kdesupport authors request it, it's a totally different discussion though.
-- 
Tom Albers