[Paraview-developers] Requiring Qt 4.6 for ParaView 3.8

[Stephane PLOIX]

I don't know about Qt forward compatibility issues, but the point Utkarsh 
made is that PV will support the same version of Qt for two releases, 
which is a clear enough policy. If Qt is good at keeping forward 
compatibility, then this will extend the life of the "minimum" Qt version, 
but those that use a version < official know that they have a version that 
can be dropped anytime. The minimum is only here as an information, and 
the developer that makes the change that increment the minimum should also 
modify the cmake command accordingly. 
Utkarsh, to help the developers in this task, could you also always 
provide a dashboard on the "minimum" version, so that changes that 
increment it will be discovered as soon as possible?

By the way, do paraview have an official policy on the interval between 
two releases?

Stephane




kmorel at sandia.gov 
Envoyé par : paraview-developers-bounces at paraview.org
08/02/2010 17:32

A
utkarsh.ayachit at kitware.com, paraview-developers at paraview.org
cc

Objet
Re: [Paraview-developers] Requiring Qt 4.6 for ParaView 3.8






How good is Qt at maintaining forward compatibility with, for example, its 
ui file format.  If all the developers are on 4.6 and someone makes a 
change with Qt Designer to one of the ui files, will the change break all 
the 4.5 builds?

-Ken


On 2/8/10 8:21 AM, "Utkarsh Ayachit" <utkarsh.ayachit at kitware.com> wrote:

Those are indeed good and valid points. We were discussing a possible 
policy and here's what we have. What does everybody think?

* There will 1 officially supported Qt version. This is the Qt version our 
binaries will be released with. The officially supported Qt version will 
remain fixed for 2 revisions e.g. 3.8 and 3.10 both will officially 
support the same Qt version. There will be a minimum Qt version below 
which it cannot compile (for 3.8 this will be Qt 4.5). However the minimum 
version may go higher in every release (but <= the official Qt version) 
depending on whether we end up using some latest Qt functionality 
 provided by the officially supported release.

* Let Qt 4.6 be an exception, since Qt 4.6 is required to build on Snow 
Leopard and it's a nightmare to support different versions on different 
platforms. So 3.8 and 3.10, will be requiring Qt 4.6 (with min. Qt 4.5)

* CMake will flag an error when the Qt version is below the minimum; a 
warning when the Qt version is below the official  (but above the min.) 
and be silent with the Qt version is same as the official or above.

* Any user-interface related issues for any Qt version, but the official 
version may not be addressed.

* We'll always have a dashboard machine compiling with the latest Qt so 
that there will be no surprises when we switch to the latest Qt.

* After two consecutive major releases (not patch releases) have stuck 
with the same QT version and it's time to upgrade to a newer Qt version, 
we'll pick the latest Qt version released at least 3 months prior to the 
release.

How does that sound? If it's acceptable, I can post it to the Wiki as the 
official policy for Qt version updating.

Utkarsh


On Mon, Feb 8, 2010 at 3:32 AM, Stephane PLOIX <stephane.ploix at edf.fr> 
wrote:

Hi, 

I think that we have to be carefull : with the branding refactoring making 
it easy to build applications on top of ParaView components, and the 
PV_INSTALL_DEVELOPMENT options, ParaView should now be considered more 
like an SDK than a stand-alone application. 

As more and more applications are built on top of PV, changing the version 
of Qt will impact all those applications, you should then have a clear 
policy regarding those versions, and give a advanced warning of any 
changed to come. 

Some possible policy would be : 
at each release of a new stable version of Qt, PV will support both the 
new and the old versions for 1 year, and drop the previous version after 
that 
or 
each stable version of ParaView will support both the lastest stable 
version of Qt and the previous one 

or whatever, but please make it a public policy so that we know what to 
expect. 

Best 
Stephane




berk.geveci at kitware.com 
Envoyé par : paraview-developers-bounces at paraview.org 07/02/2010 21:48 
A 
burlen.loring at gmail.com 
cc 
paraview-developers at paraview.org 
Objet 
Re: [Paraview-developers] Requiring Qt 4.6 for ParaView 3.8 




I wouldn't object to supporting 4.5 and 4.6. I think setting up 1-2 
dashboards to verify building with 4.5 would be enough. We don't run into 
Qt specific bugs too often anyway. I defer to Utkarsh though.

Also, if there is an attractive feature on the latest version of Qt that 
will make our lives much easier, we are likely to move to it and not 
support the previous version. So, I don't want to have an official rule 
about supporting more than 1 version.

-berk


On Sun, Feb 7, 2010 at 3:08 PM, burlen <burlen.loring at gmail.com <
mailto:burlen.loring at gmail.com> > wrote: 
Will this mean that PV won't build with any thing less than Qt 4.6?
I wonder if it would make sense to have a small range of supported 
versions rather than a single one?

It's currently the case that with qt anything less than 4.5 pv fails to 
compile (even if you remove the version test in cmakelists) because pv 
uses some qt classes that were only added to 4.5. In my opinion it would 
be a burden to pv users to get too far ahead of the various KDE supported 
distro's packages. eg. Kubuntu 9.10 reports qt version 4.5.2. KUbuntu 
8.04.4 LTS reports qt version 4.3.4.