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

/branches/safe-kdesupport-for-trunk/
/branches/safe-kdesupport-for-trunk/strigi/
etc.

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
numbers.

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.

Cheers,
Benoit


More information about the release-team mailing list