[PyKDE] 10.0 official rpms for PyKDE

[Joachim Werner]

> 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