On Sunday 28 September 2008 06:48:51 Tom Albers wrote: > Hi, > > I think we have come to a conclusion, but not to a descision. Let's try to > change that. Below you find the proposal based on the various mails to this > list. I will wait untill there are a few supporters for this proposal, before > posting it to k-c-d and k-d. Improvements are welcome too. >
I support this plan. I also volunteer to help create the necessary CMakeLists.txt files. > ------------------------------------------------------------------------------------------------------------------------ > > The release-team has decided to change the organisation of the kdesupport > system we use. Please read the details below. > > Problem > ------------ > KDE development is devided in several branches, especially the current stable > KDE branch and the unstable development branch in trunk. kdesupport libraries > are independant of KDE, but KDE depends on them. At this moment there is no > indication at all which kdesupport library should be used for a certain KDE > branch. > > We want a simple system for developers to just know for sure that you got the > right kdesupport libraries when you want to compile a KDE tree completely > from subversion. > > Solution > ------------ > For each main kde tree we will create a tag. For example for the current > stable KDE release we create a tags/kdesupport-for-4.1/. Within that folder > there are (cheap)copies of the kdesupport libraries which should be used for > compiling the KDE 4.1 tree. For example: > 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) > Also, it will contain a CMake file, so all subdirectories can be build in one > go. So if you want KDE4.1, just simply checkout this tag and you are done. > > The same will go for trunk, so we will create a kdesupport-for-trunk. This > also contains copies to the right version of the kdesupport libraries needed > to build trunk. That means developers have a choise: either use > trunk/kdesupport where development takes place, so that could lead to > breakage in for example kdelibs but you can probably fix them, or you choose > to compile KDE trunk with kdesupport from /tags/kdesupport-for-trunk and you > are sure kdelibs trunk compiles from it. > > Who > ------------ > The kdesupport maintainers should make sure that the right version if > available in each tag. If they release a new version they update the copy > with a simple svnn rm + svn cp. If some kdesupport developers think everyone > should just use their trunk, they could just regularly rm+cp the "tag" from > their trunk. An svn external would have been more appropiate in that case, > but that's unfortunatly not an option. > > When > ------------ > We would like to have this infrastructure in place at november 1st. > > Tom Albers > w/RT-hat _______________________________________________ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
