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, [EMAIL PROTECTED], sponsored by Trolltech to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org). _______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
