kdesupport changes

Benoit Jacob jacob.benoit.1 at gmail.com
Tue Sep 16 14:23:10 CEST 2008

2008/9/14, Allen Winter <winter at kde.org>:
> In the meantime, dfaure's proposal (snippet below) looks good.  I think this
> is basically
> what many of us have suggested but for some reason the simplicity got lost
> in the noise.
> Should we also commit a tags/kdesupport-for-4.1/CMakeLists.txt file so folks
> can
> easily build all of the kdesupport-for-4.1 stuff in 1 easy step?

Seems like a must to me.

> dfaure writes:
> 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 :-)

Great, and going further I think we also need something like


The idea is that people building trunk may also want to go the safer
way (tags) and may also not like to have to remember 10 version

I suppose that this should be a branch instead of a tag, as the
version numbers required by trunk evolve.

Unless we do that, we'll inevitably have most people building
trunk/KDE using trunk/kdesupport. Instead, what we want is what David
suggested: that a vast majority of people use tags, with still the
possibility of using trunk/kdesupport.

If you don't like the naming of the directories (yes it is confusing)
then one can reverse things, that is, make instead /trunk/kdesupport
be a collection of tags of libraries developed in a
/branches/kdesupport directory. So that /trunk/kdesupport would be
again the recommeded kdesupport for building trunk.


More information about the release-team mailing list