Re: kdesupport branch for 4.0.x
On Friday 21 March 2008, Andras Mantia wrote: as of now, kdesupport is not branched (except for 3.5), nor it is tagged. This can cause confusion as see on this thread: http://lists.kde.org/?l=kde-develm=120587525306937w=2 one shouldn't use kdesupport. preferably one should use the released versions or alternatively use the distro provided packages. I'm fine with branching kdesupport for 4.0 and 4.1, but I don't want to tag it with each KDE release - after all we're NOT releasing kdesupport. Greetings, Dirk ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdesupport branch for 4.0.x
On Tuesday 25 March 2008, Dirk Mueller wrote: On Friday 21 March 2008, Andras Mantia wrote: as of now, kdesupport is not branched (except for 3.5), nor it is tagged. This can cause confusion as see on this thread: http://lists.kde.org/?l=kde-develm=120587525306937w=2 one shouldn't use kdesupport. preferably one should use the released versions or alternatively use the distro provided packages. I'm fine with branching kdesupport for 4.0 and 4.1, but I don't want to tag it with each KDE release - after all we're NOT releasing kdesupport. I think branching is enough and should satisfy everybody. Andras -- Quanta Plus developer - http://quanta.kdewebdev.org K Desktop Environment - http://www.kde.org signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdesupport branch for 4.0.x
On Tuesday 25 March 2008, Tom Albers wrote: I think it is the responsibility of the kdesupport library maintainer to clearly indicate which released version of their library should be used to compile branch and trunk. So I'm against branching, tagging or releasing. But then, why do we have kdesupport at all if we should use the released versions only? Andras -- Quanta Plus developer - http://quanta.kdewebdev.org K Desktop Environment - http://www.kde.org signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdesupport branch for 4.0.x
At Tuesday 25 March 2008 12:45, you wrote: On Tuesday 25 March 2008, Tom Albers wrote: I think it is the responsibility of the kdesupport library maintainer to clearly indicate which released version of their library should be used to compile branch and trunk. So I'm against branching, tagging or releasing. But then, why do we have kdesupport at all if we should use the released versions only? Andras They can say use trunk to compile trunk. I think it's a matter of communicating, not a technical problem. A simple table on techbase would solve this, I think. -- Tom Albers ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdesupport branch for 4.0.x
On 2008-03-25 22:07, Tom Albers wrote: I think it is the responsibility of the kdesupport library maintainer to clearly indicate which released version of their library should be used to compile branch and trunk. So I'm against branching, tagging or releasing. But then, why do we have kdesupport at all if we should use the released versions only? They can say use trunk to compile trunk. I think it's a matter of communicating, not a technical problem. A simple table on techbase would solve this, I think. Which leads to a problem of keeping that table uptodate and also allowing for some method to automatically parse the fields of that table so manual copy n paste is not needed for folks to complete a build from trunk. I can imagine this is why kdesupport came into being in the first place, something that can be reliably fetched automatically with standard tools. I was in the process of looking for the right list to ask if exiv2 could be included in kdesupport when I saw this post. Now it's clear that kdesupport is ephemeral and can not be relied upon from the KDE repositories and I need to come up with some other method to fetch all of kdesupport for the long term, not just exiv2. Just an idle thought, an RSS feed would be easier to parse than a webpage. A simple CSV file could be parsed by a bash script. --markc ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdesupport branch for 4.0.x
On Tuesday 25 March 2008, Mark Constable wrote: I can imagine this is why kdesupport came into being in the first place, something that can be reliably fetched automatically with standard tools. Exactly, this is my idea. If you want to build trunk, you use kdesupport from trunk and you can trust it works. If you build 4.0 branch (not a release!), you use kdesupport 4.0 branch and you trust that it will work. This is really only for developers, or those who want to follow the development closely, not those building releases from source. For them, there should be officially released packages, in the best case provided by their distribution. Andras -- Quanta Plus developer - http://quanta.kdewebdev.org K Desktop Environment - http://www.kde.org signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdesupport branch for 4.0.x
On Tuesday 25 March 2008, Tom Albers wrote: I just don't see the need, if the kdesupport authors request it, it's a totally different discussion though. Where are kdesupport apps developed? In /trunk/kdesupport? In other svn servers? Again why do we keep it here, if it is how you said? Or why don't we put every single KDE dependency in /trunk/kdesupport? Well, I know the answers, they are developed in the KDE svn server. So they should follow the same rules as for every other application there: they have a development (trunk) version and a stable branch. The trunk can be trunk/kdesupport, the stable can be branches/4.0/kdesupport. What is done now is that trunk is trunk/kdesupport and the stable versions are spread around branches/ , which I find...a little weird. But whatever, branches/4.0/kdesupport could be just a bunch of externals, if they like how it is now. But maybe I have a weird logic, and everything is beautiful and nice how it is. Andras -- Quanta Plus developer - http://quanta.kdewebdev.org K Desktop Environment - http://www.kde.org signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
kdesupport branch for 4.0.x
Hi, as of now, kdesupport is not branched (except for 3.5), nor it is tagged. This can cause confusion as see on this thread: http://lists.kde.org/?l=kde-develm=120587525306937w=2 I'd like to propose either tagging a version of kdesupport with each KDE release (tagging a version that is known to work with that release) or create branches for each KDE release. So trunk/kdesupport would be OK for trunk/KDE, branches/kdesupport/4.0 for the KDE 4.0.x releases, and so on. Even if most applications from kdesupport are provided by distributions , doing such branching would help those compiling regularly from source to get all KDE and its dependencies from one places, the KDE SVN, without hunting on project pages for the latest release that works with a specific KDE version. Aside of the release team (doing the tagging/branching), this proposal needs to be communicated to the maintainers of apps/libraries inside kdesupport, so they update the branched version in case they develop their stuff somewhere else. Andras -- Quanta Plus developer - http://quanta.kdewebdev.org K Desktop Environment - http://www.kde.org signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdesupport branch for 4.0.x
On Friday 21 March 2008, Andras Mantia wrote: without hunting on project pages for the latest release that works with a specific KDE version. Does this mean that those libs in kdesupport are making incompatible changes !?? Sorry, I didn't follow the kde-devel thread -- but if the latest version of the libs doesn't work then it means they are not keeping SC/BC... -- 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 release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdesupport branch for 4.0.x
On 21.03.08 13:46:24, David Faure wrote: On Friday 21 March 2008, Andras Mantia wrote: without hunting on project pages for the latest release that works with a specific KDE version. Does this mean that those libs in kdesupport are making incompatible changes !?? Sorry, I didn't follow the kde-devel thread -- but if the latest version of the libs doesn't work then it means they are not keeping SC/BC... No, its not about the libraries keeping BC/SC. In this particular case soprano just switched to Qt4.4 as dependency due to using Qt4.4-only API. And this obviously leads to confusion, unless there's a complete 4.0-branch for kdesupport. Andreas -- You will obey or molten silver will be poured into your ears. signature.asc Description: Digital signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdesupport branch for 4.0.x
A Divendres 21 Març 2008, Andreas Pakulat va escriure: On 21.03.08 13:46:24, David Faure wrote: On Friday 21 March 2008, Andras Mantia wrote: without hunting on project pages for the latest release that works with a specific KDE version. Does this mean that those libs in kdesupport are making incompatible changes !?? Sorry, I didn't follow the kde-devel thread -- but if the latest version of the libs doesn't work then it means they are not keeping SC/BC... No, its not about the libraries keeping BC/SC. In this particular case soprano just switched to Qt4.4 as dependency due to using Qt4.4-only API. And this obviously leads to confusion, unless there's a complete 4.0-branch for kdesupport. You can always use a released version like soprano 2.0, right? Albert Andreas ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdesupport branch for 4.0.x
On 21.03.08 16:43:16, Albert Astals Cid wrote: A Divendres 21 Març 2008, Andreas Pakulat va escriure: On 21.03.08 13:46:24, David Faure wrote: On Friday 21 March 2008, Andras Mantia wrote: without hunting on project pages for the latest release that works with a specific KDE version. Does this mean that those libs in kdesupport are making incompatible changes !?? Sorry, I didn't follow the kde-devel thread -- but if the latest version of the libs doesn't work then it means they are not keeping SC/BC... No, its not about the libraries keeping BC/SC. In this particular case soprano just switched to Qt4.4 as dependency due to using Qt4.4-only API. And this obviously leads to confusion, unless there's a complete 4.0-branch for kdesupport. You can always use a released version like soprano 2.0, right? Sure. The real problem is that our build documentation isn't up to date wrt. to building from a branch vs. building from trunk. Andreas -- You will always get the greatest recognition for the job you least like. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
