Re: kdereview closed?
On Tuesday 06 May 2008, Kevin Ottens wrote: Le mardi 6 mai 2008, Sebastian Kuegler a écrit : A couple of problems: 1) last I knew, the decibel buildsystem was messy 2) we never actually announced it. so maybe nobody looked at it in kdereview. Announce it now on kcd and move it in a week. Use that week to fix things? Kevin has reviewed it, and he's a bitch at that. If you're referring to me I never reviewed Decibel. Wanted to but never found the time... I reviewed decibel now, see kde-core-devel. (but I'm no API bitch, it's more of an implementation review, other kinds of review - buildsystem / API - are welcome) -- 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
breaking BIC for new addon libs in minor releases (was: Re: Goals? How are we doing?)
Am Dienstag, 6. Mai 2008, um 17:17 Uhr, schrieb Andreas Pakulat: On 05.05.08 21:24:52, Andras Mantia wrote: Actually would be nice to see at least a KDevPlatform release. I know its hard, but maybe makes sense, just like kdelibs was released before the actual KDE 4.0.0. Well, we could probably do that, but without any guarantees regarding binary compatibility. Especially not for the interfaces, shell, project, sublime, language and vcs libraries. I have a similar problem. I know at least one person which would like to make use of the Okteta libraries (implementing a specialised ByteArrayModel) in a 3rd-party project after the 4.1 release. But I know for sure the API will change for 4.2 again, so I do not install any headers. Right now I had to tell him bad luck... I did not find an explicit rule for this on techbase.kde.org, just remember the general unwritten rule ensure binary interface compatibility in minor releases. Could this rule be made mandatory only for kdelibs and kdepimlibs? So young and evolving libraries could follow the principle release often and early and get some more feedback, until they are mature enough to keep BIC till a next major release. Those interested to make use of such libraries would know of the risks and have a reason for still using them. Of course the API documentation should contain proper big warnings. Friedrich ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: breaking BIC for new addon libs in minor releases (was: Re: Goals? How are we doing?)
On 06.05.08 17:56:11, Friedrich W. H. Kossebau wrote: Am Dienstag, 6. Mai 2008, um 17:17 Uhr, schrieb Andreas Pakulat: On 05.05.08 21:24:52, Andras Mantia wrote: Actually would be nice to see at least a KDevPlatform release. I know its hard, but maybe makes sense, just like kdelibs was released before the actual KDE 4.0.0. Well, we could probably do that, but without any guarantees regarding binary compatibility. Especially not for the interfaces, shell, project, sublime, language and vcs libraries. I have a similar problem. I know at least one person which would like to make use of the Okteta libraries (implementing a specialised ByteArrayModel) in a 3rd-party project after the 4.1 release. But I know for sure the API will change for 4.2 again, so I do not install any headers. Right now I had to tell him bad luck... I did not find an explicit rule for this on techbase.kde.org, just remember the general unwritten rule ensure binary interface compatibility in minor releases. Thats currently only a rule for kdelibs+kdepimlibs - AFAIK. Other modules in KDE/ need to decide on that themselves, for example kdegames broke BC in their libkdegames library between 4.0 and 4.1. The techbase page explicitly says that the guidelines are not mandatory. Andreas -- Tomorrow, you can be anywhere. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: breaking BIC for new addon libs in minor releases (was: Re: Goals? How are we doing?)
Op dinsdag 06 mei 2008 17:56 schreef u: Am Dienstag, 6. Mai 2008, um 17:17 Uhr, schrieb Andreas Pakulat: On 05.05.08 21:24:52, Andras Mantia wrote: Actually would be nice to see at least a KDevPlatform release. I know its hard, but maybe makes sense, just like kdelibs was released before the actual KDE 4.0.0. Well, we could probably do that, but without any guarantees regarding binary compatibility. Especially not for the interfaces, shell, project, sublime, language and vcs libraries. I have a similar problem. I know at least one person which would like to make use of the Okteta libraries (implementing a specialised ByteArrayModel) in a 3rd-party project after the 4.1 release. But I know for sure the API will change for 4.2 again, so I do not install any headers. Right now I had to tell him bad luck... I did not find an explicit rule for this on techbase.kde.org, just remember the general unwritten rule ensure binary interface compatibility in minor releases. From the policies section: http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++ In the KDE project, we will provide binary compatibility within the life-span of a major release. Could this rule be made mandatory only for kdelibs and kdepimlibs? So young and evolving libraries could follow the principle release often and early and get some more feedback, until they are mature enough to keep BIC till a next major release. Those interested to make use of such libraries would know of the risks and have a reason for still using them. Of course the API documentation should contain proper big warnings. I disagree. I think it is a must to be BC between minor releases. If you want to be bic public, go to extragear/libs untill you are ready... Best, Toma___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: breaking BIC for new addon libs in minor releases (was: Re: Goals? How are we doing?)
Am Dienstag, 6. Mai 2008, um 18:15 Uhr, schrieb Andreas Pakulat: On 06.05.08 17:56:11, Friedrich W. H. Kossebau wrote: Am Dienstag, 6. Mai 2008, um 17:17 Uhr, schrieb Andreas Pakulat: On 05.05.08 21:24:52, Andras Mantia wrote: Actually would be nice to see at least a KDevPlatform release. I know its hard, but maybe makes sense, just like kdelibs was released before the actual KDE 4.0.0. Well, we could probably do that, but without any guarantees regarding binary compatibility. Especially not for the interfaces, shell, project, sublime, language and vcs libraries. I have a similar problem. I know at least one person which would like to make use of the Okteta libraries (implementing a specialised ByteArrayModel) in a 3rd-party project after the 4.1 release. But I know for sure the API will change for 4.2 again, so I do not install any headers. Right now I had to tell him bad luck... I did not find an explicit rule for this on techbase.kde.org, just remember the general unwritten rule ensure binary interface compatibility in minor releases. Thats currently only a rule for kdelibs+kdepimlibs - AFAIK. Other modules in KDE/ need to decide on that themselves, for example kdegames broke BC in their libkdegames library between 4.0 and 4.1. Was libkdegames public for 3rd-party development, i.e. have the headers been installed? The techbase page explicitly says that the guidelines are not mandatory. Which page is that? Friedrich ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: breaking BIC for new addon libs in minor releases (was: Re: Goals? How are we doing?)
Op dinsdag 06 mei 2008 18:30 schreef u: I disagree. I think it is a must to be BC between minor releases. For everything? Yes. If you want to be bic public, go to extragear/libs untill you are ready... What would this change for 3rd-party developers? You can make a release whenever you like and bump the major so version of the lib as you like in each release. For me it would be more work, as I would have development spanned between extragear/libs and kdeutils. And it would add an additional (if only soft) dependency between modules. No, as long as you make releases from the library, it's is just another 'external' dependency. As long as it is not a cyclic dependency as we now face with libkipi, it is not a problem. Toma___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: breaking BIC for new addon libs in minor releases (was: Re: Goals? How are we doing?)
Am Dienstag, 6. Mai 2008, um 18:39 Uhr, schrieb Tom Albers: Op dinsdag 06 mei 2008 18:30 schreef u: I disagree. I think it is a must to be BC between minor releases. If you want to be bic public, go to extragear/libs untill you are ready... What would this change for 3rd-party developers? You can make a release whenever you like and bump the major so version of the lib as you like in each release. That would be me, but I asked for 3rd-party developers. Then, I know I would not make releases independent of the KDE ones, because I would develop the libs and the program together. So nothing would change for 3rd parties, just another location. For me it would be more work, as I would have development spanned between extragear/libs and kdeutils. And it would add an additional (if only soft) dependency between modules. No, as long as you make releases from the library, it's is just another 'external' dependency. As long as it is not a cyclic dependency as we now face with libkipi, it is not a problem. We misunderstand each other? kdeutils/okteta would depend on extragear/libs/okteta. Now it does not. Think of the packagers. And checkouts of KDE's repository. Friedrich ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: breaking BIC for new addon libs in minor releases (was: Re: Goals? How are we doing?)
On 06.05.08 18:22:09, Friedrich W. H. Kossebau wrote: Am Dienstag, 6. Mai 2008, um 18:15 Uhr, schrieb Andreas Pakulat: On 06.05.08 17:56:11, Friedrich W. H. Kossebau wrote: Am Dienstag, 6. Mai 2008, um 17:17 Uhr, schrieb Andreas Pakulat: On 05.05.08 21:24:52, Andras Mantia wrote: Actually would be nice to see at least a KDevPlatform release. I know its hard, but maybe makes sense, just like kdelibs was released before the actual KDE 4.0.0. Well, we could probably do that, but without any guarantees regarding binary compatibility. Especially not for the interfaces, shell, project, sublime, language and vcs libraries. I have a similar problem. I know at least one person which would like to make use of the Okteta libraries (implementing a specialised ByteArrayModel) in a 3rd-party project after the 4.1 release. But I know for sure the API will change for 4.2 again, so I do not install any headers. Right now I had to tell him bad luck... I did not find an explicit rule for this on techbase.kde.org, just remember the general unwritten rule ensure binary interface compatibility in minor releases. Thats currently only a rule for kdelibs+kdepimlibs - AFAIK. Other modules in KDE/ need to decide on that themselves, for example kdegames broke BC in their libkdegames library between 4.0 and 4.1. Was libkdegames public for 3rd-party development, i.e. have the headers been installed? AFAIK some apps in extragear and playground use it, AFAIK. The techbase page explicitly says that the guidelines are not mandatory. Which page is that? http://techbase.kde.org/index.php?title=Policies/Library_Code_Policy Right at the top. Andreas -- Life, loathe it or ignore it, you can't like it. -- Marvin, Hitchhiker's Guide to the Galaxy signature.asc Description: Digital signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: breaking BIC for new addon libs in minor releases (was: Re: Goals? How are we doing?)
On 06.05.08 19:01:15, Tom Albers wrote: Op dinsdag 06 mei 2008 18:46 schreef u: Am Dienstag, 6. Mai 2008, um 18:39 Uhr, schrieb Tom Albers: Op dinsdag 06 mei 2008 18:30 schreef u: I disagree. I think it is a must to be BC between minor releases. If you want to be bic public, go to extragear/libs untill you are ready... What would this change for 3rd-party developers? You can make a release whenever you like and bump the major so version of the lib as you like in each release. That would be me, but I asked for 3rd-party developers. Then, I know I would not make releases independent of the KDE ones, because I would develop the libs and the program together. So nothing would change for 3rd parties, just another location. The difference is that you have a proper versioning with library version numbers. 3rd party devels can check for that and adapt their code to those versions. What has library versioning to do with keeping BC? If a lib breaks BC it increases its so version and can also adjust its major version number. The library doesn't have to follow the global KDE version number at all, for example the kdevplatform libs don't do it for the plain reason that its not very honest to say they are version 4.x. That version would indicate a matureness the library simply doesn't have. I like to keep minor release from KDE BC and more importantly 3rd party devels should be able to rely on that. Right, people using a lib need to rely on that lib keeping BC within a major version, that doesn't mean a library can't change BC between releases, it just means it needs to increase its major version. And if the library devs want to release it with KDE and have it as KDE module thats fine too - IMHO. Andreas -- You are a fluke of the universe; you have no right to be here. signature.asc Description: Digital signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Goals? How are we doing?
On Tuesday 06 May 2008, Andreas Pakulat wrote: Well, we could probably do that, but without any guarantees regarding binary compatibility. Especially not for the interfaces, shell, project, sublime, language and vcs libraries. Yes, this is a problem. But still would be nice to release, like e.g v3.99 of the platform (or 0.99 I don't remember now what was decided about the version numbering) and stating that BC is not guaranteed. And of course name the libraries in a form that the final 4.0 libraries will have different so versions. 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: breaking BIC for new addon libs in minor releases (was: Re: Goals? How are we doing?)
A Dimarts 06 Maig 2008, Tom Albers va escriure: Op dinsdag 06 mei 2008 18:30 schreef u: I disagree. I think it is a must to be BC between minor releases. For everything? Yes. I disagree, this was never a promise we made outside kdelibs + kdepimlibs + maybe kdebase-runtime. I agree it is good not changing SC/BC for the sake of doing it but let's not make things imposible to work, or do you want libokteta (e.g) to virtually be forked until KDE5 if current api is not good enough? Albert If you want to be bic public, go to extragear/libs untill you are ready... What would this change for 3rd-party developers? You can make a release whenever you like and bump the major so version of the lib as you like in each release. For me it would be more work, as I would have development spanned between extragear/libs and kdeutils. And it would add an additional (if only soft) dependency between modules. No, as long as you make releases from the library, it's is just another 'external' dependency. As long as it is not a cyclic dependency as we now face with libkipi, it is not a problem. Toma ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
