kdesupport Policy

[David Faure]

On Thursday 11 September 2008, Dirk Mueller wrote:
> > Well what I was thinking is we could make a kdesupport 4.1 branch for
> > instance to do the same thing. (unless you mean kdesupport-stable which
> > simply tracks the latest stable release of KDE).
> 
> It doesn't make sense to me - the software in kdesupport is not released on 
> the same schedule like KDE,

Yes, this is why the best solution is a kdesupport-for-4.1 directory with
_tags_ of released kdesupport things, as others mentionned before.

> and often enough newer versions work just fine with  
> older versions of KDE. 

But everyone was told to use branches/phonon/4.2 instead of phonon trunk,
for kdelibs-4.1, and this created a lot of confusion, and scripted-builds breakage, etc.
(OK the fact that one had to compile Qt with --no-phonon would have broken
those scripts anyway, my main point is that having to switch to a different branch
for each kdesupport software is too much hassle).

Here's what I have in mind:
tags/kdesupport-for-4.1/
tags/kdesupport-for-4.1/phonon/    (svn cp'ed from tags/phonon/4.2.0)
tags/kdesupport-for-4.1/strigi/    (svn cp'ed from tags/strigi/strigi/0.5.11)
tags/kdesupport-for-4.1/qca/    (svn cp'ed from tags/qca/2.0.1)
etc.
Yes, just for convenience. Because nobody can remember 10 version numbers
that keep changing, for things he's not working on :-)

Whenever the developers of one of the above products fix bugs and want other
kde developers/users to benefit from these fixes, they just have to make a new
release (well, at least a new tag), and to update the copy in tags/kdesupport-for-4.1/
(svn rm + svn cp). I'd rather not use svn:externals for this, at least until
svn.kde.org uses svn-1.5, it's currently too much trouble in many cases
(slowness, firewalls, anonsvn being down, or auth issues if not using anonsvn).

And this is where it gets better: if some kdesupport developers think everyone
should just use their trunk, they could just regularly rm+cp the "tag" from their trunk
(yes, -that- is where a nice relative external would be much better :)
On the other hand, I believe we don't need this at all. tags/kdesupport-for-4.1
should be stable software, while kdelibs-trunk developers should be able to just
use kdesupport trunk. But that's just my opinion, I'm fine with a tags/kdesupport-for-trunk
solution pointing to last releases as well.

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).