[Kst] Qt 3.2

C. Barth Netterfield netterfield at physics.utoronto.ca
Fri Nov 14 18:55:28 CET 2003


OK,

Lets say: minimize upgrade requirements, subject to:

	-upgrade no sooner than 4 months after a release
	-upgrade no more often than 1x per 12 months
	-only upgrade if doing so provides a significant enhancement (like kjs!)

cbn

On Friday 14 November 2003 12:48 pm, George Staikos wrote:
> On Friday 14 November 2003 12:25, C. Barth Netterfield wrote:
> > We need to discuss an library upgrade policy:
> >
> > How does this sound?
> >
> > I suggest that we allow enhancements which require KDE/Qt upgrades 3-4
> > months after a ?. or ?.? upgrade to KDE is released, at most once per 12
> > months. This delay is intended to allow the new KDE/qt to be included in
> > the major distributions.  The rate is intended to allow us to keep up
> > with major enhancements to the library without making people upgrade too
> > often.
>
>    Actually I think this is unnecessary.  We can continue to support KDE
> 3.1 for quite a long time.  I would suggest that we can continue to work on
> KDE 3.1 until 3-4 months after KDE 4 comes out.  I only posted this because
> using Qt 3.2 will surely result in me accidentally committing 3.2-only code
> by mistake.  I expect I will have a 3.1 machine up and running for testing
> again in 2 weeks.
>
>    Really, the API changes in KDE 3.2 don't justify Kst moving to it IMHO. 
> We do want KJSEmbed eventually, but it's effectively a plugin and we can
> check for KDE 3.2 at compile time.
>
> > The trickiest will be the 3.? to 4.? upgrade which will break source code
> > compatibility.  When the major dists are shipping 4.0, and all the older
>
>   Hopefully mostly just binary compatibility, but I'm not sure what the
> finally decision at Trolltech will be.
>
> > I still have people (hard-core stable debianites) running the 2.2
> > versions
> >
> > :-(
>
>    The 2->3 upgrade is so valuable that it's not worth supporting 2 still.
>
>    The last call on all of this is yours, but I think we can easily provide
> further backward compatibility without any problems.




More information about the Kst mailing list