Re: Re: Re: playground-libs/libkvkontakte has moved to kdereview
A Dissabte, 3 de setembre de 2011, Alexander Potashev vàreu escriure: 2011/9/2 Albert Astals Cid aa...@kde.org: Personally i prefer things not to be released from kdereview. Gilles Caulier (digiKam and KIPI-Plugins maintainer) told me that the tarball for KIPI-Plugins 2.1.0 will probably be created tomorrow. Therefore I hope to release libkvkontakte also tomorrow. Should now this library be moved to extragear/libs or playground/libs? Seems everyone was happy with review so move it to extragear? Anyway i prefer things not to be released from playground either (yes i know lots of people do it, that's why it is my personal opinion) so if you can not get it to be moved or prefer to stay in kdereview a bit more please do not let my personal opinion block you from doing a release. Albert -- Alexander Potashev
Re: Re: Re: playground-libs/libkvkontakte has moved to kdereview
2011/9/4 Albert Astals Cid aa...@kde.org: Seems everyone was happy with review so move it to extragear? Anyway i prefer things not to be released from playground either (yes i know lots of people do it, that's why it is my personal opinion) so if you can not get it to be moved or prefer to stay in kdereview a bit more please do not let my personal opinion block you from doing a release. I've already decided that libkvkontakte will be released (i.e. tarball-ed) today as part of digiKam SC, because otherwise we either need to remove the VKontakte export plugin from kipi-plugins or release libkvkontakte later in a separate tarball making life harder for packagers. -- Alexander Potashev
Re: Re: Re: playground-libs/libkvkontakte has moved to kdereview
A Dijous, 25 d'agost de 2011, Alexander Potashev vàreu escriure: 2011/8/25 Albert Astals Cid aa...@kde.org: I thought you were going to get rid of the private members and use a d-pointer instead? What is the point of this? I think it will be OK to keep all class members in the main (public) classes and use d-ptr only in case of real necessity. The point is that usually you do not know what the library will end up doing and by using d-pointers everywhere you make it easier for yourself to maintain binary compatibility in the future. But this is of course something you as maintainer of the library have to decide if it is worth or not. Albert -- Alexander Potashev
Re: Re: Re: playground-libs/libkvkontakte has moved to kdereview
2011/8/25 Albert Astals Cid aa...@kde.org: The point is that usually you do not know what the library will end up doing and by using d-pointers everywhere you make it easier for yourself to maintain binary compatibility in the future. But in the case that most classes won't grow in the future by using my strategy (keeping d-ptr NULL when possible) we cut down the number of memory allocations, and also simplify the existing code that doesn't work with the private class' data. So, I'm going to keep following the current strategy. -- Alexander Potashev
