KDE 3.2.3 is due in the next few weeks (last time I looked at the KDE release schedule), and the next PyKDE release should be ready very shortly after that. Phil has just released sip 3.10.2 (which the next PyKDE release will require) and hopefully the last sip4 rc (which PyKDE should work with), so sip 4.0 should be fairly close. Phil is also planning a PyQt update shortly. So everything should be in sync then.
If the last kdelibs 3.3rc is binary compatible with the final release, I could have PyKDE complete *before* the final. But then in theory, 3.3 is supposed to be binary compatible with 3.2, I believe.
The problem in doing that is that the final rpms from SuSE, Mankdrake and whatever RH/Fedora is doing now are never compatible with "official" KDE source code (I get the source either from kde.org or uk.kde.org) - eg KFileShare::setShared on SuSE 3.1.x later rpm releases, similar stuff on Mdk or RH, QXEmbed with some distros, etc. It only takes one modified or deleted method to make PyKDE essentially unusable - PyKDE binds nearly every method in the kdelibs modules it supports, which most apps don't do.
That being the case, I'd be shooting myself in the foot by doing a release ahead of the official KDE 3.3 rpms and not testing against those. Usually, I only build against the latest KDE on SuSE, but test earlier versions against Mdk and RH.
From the SUSE point of view I'd be fine if I could get hold of late betas or release candidates a week or two after the KDE release that preceeds our SUSE LINUX product. The enterprise products are always based on the same code base, and we can make sure during the enterprise beta phase that we become aware of any changes in KDE that would break PYKDE.
That would mean that we can get things in sync during the beta phase and release the latest KDE with the latest bindings.
From what you are saying this might work for the next SUSE LINUX. :-)
I can't speak for the other distros, but I guess none of them release their final products earlier than a couple of weeks after a major KDE release ...
I have enough problems when I do test (eg, the current problems with kdeui not finding kdefx on Mdk 10.0, which doesn't happen on Mdk 9.x, any SuSE after 8.1 or RH9.x).
If there are any automated tests we could run them as part of our QA efforts. And of course we can provide betas to you ...
Cheers
Joe
-- Joachim Werner SUSE RD-TPM
_______________________________________________ PyKDE mailing list [EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
