[PyKDE] Updating to the latest versions of eric/sip/PyQt/PyKDE ...

Phil Thompson phil at riverbankcomputing.co.uk
Tue Apr 27 20:19:00 BST 2004


On Tuesday 27 April 2004 12:32 pm, Joachim Werner wrote:
> Hi!
>
> We have shipped the following versions with SUSE LINUX 9.1:
>
> - eric-3.3.1
> - sip-3.10.1
> - PyQt-3.11
>
> PyKDE wasn't ready for shipment at the time the 9.1 distro was prepared.
>
> Now we are in the process of preparing an SDK (add-ons and development
> tools that are not part of the SUSE LINUX Server, but needed to develop
> software for it).
>
> The problem we have (as usual) is that on the one hand we want to ship
> with the latest code, but on the other hand we have to keep the
> enterprise Linux distribution stable for a long time and don't want to
> have to maintain several versions of the same tool.
>
> My question to the maintainers of the above products:
>
> Considering that the SDK will have an expected lifetime of at least one
> year, would you feel comfortable with us shipping the above versions (+
> PyKDE 3.11 if everything works out as planned) or should we use later
> versions?
>
> Updating eric to 3.4.1 should be no problem, but my main concern is sip.
>   sip 4 doesn't seem to be completely working with PyKDE yet.

I will be deprecating SIP v3 as soon as I release the final SIP v4.0 (which is 
just waiting for me to finish the documention). SIP v3 will still be 
available (and will receive fixes for any critical bugs) for quite a while (a 
year sounds reasonable). I don't expect there to be a SIP v3.11.

The main reason for deprecating SIP v3 is to encourage people to move to v4 
and shake out any remaining obscure bugs.

All things being equal, I'd stick with SIP v3. If you were to ask in 3-6 
months time I'd say SIP v4.

> The real problem is compatibility of applications written using those
> tools/bindings. If we can make sure that a Python program that was
> written against the current PyQt and/or PyKDE will run without problems
> on later versions then updating those wouldn't cause me any headaches.

That shouldn't be an issue as far as PyQt is concerned.

> I'm planning to make current versions of the "Qt Python Toolchain"
> available as unofficial builds, but we are not going to have the
> manpower to officially support those (e.g. provide YOU updates) ...
>
> Cheers
>
> Joachim

Phil




More information about the PyQt mailing list