As far as ui files go, we have had issues in the past where ui file generated from Qt 4.4+ did not work with Qt 4.3 (I may have the version numbers wrong). So yea, if developer does indeed commit a ui file generated with a new Qt, we may have to update the min version.<div>
<br></div><div>Stephane, sure, that&#39;s a good idea about keeping a dashboard for the minimum Qt version as well. It may not necessarily try to run the tests but at least test that compilation works and will avoid surprises.</div>
<div><br></div><div>As far as the ParaView release schedule goes, currently the plan is to have a major release (increment in the minor version number) every 6 months. </div><div><br></div><div>Utkarsh<br><br><div class="gmail_quote">
On Mon, Feb 8, 2010 at 12:04 PM, Stephane PLOIX <span dir="ltr">&lt;<a href="mailto:stephane.ploix@edf.fr">stephane.ploix@edf.fr</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br><font size="2" face="sans-serif">I don&#39;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 &quot;minimum&quot;
Qt version, but those that use a version &lt; 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.  </font>
<br><font size="2" face="sans-serif">Utkarsh, to help the developers in this
task, could you also always provide a dashboard on the &quot;minimum&quot;
version, so that changes that increment it will be discovered as soon as
possible?</font>
<br>
<br><font size="2" face="sans-serif">By the way, do paraview have an official
policy on the interval between two releases?</font>
<br>
<br><font size="2" face="sans-serif">Stephane<br>
</font>
<br>
<br>
<br>
<p></p><table width="100%">
<tbody><tr valign="top">
<td width="40%"><font size="1" face="sans-serif"><b><a href="mailto:kmorel@sandia.gov" target="_blank">kmorel@sandia.gov</a></b> </font>
<br><div class="im"><font size="1" face="sans-serif">Envoyé par : <a href="mailto:paraview-developers-bounces@paraview.org" target="_blank">paraview-developers-bounces@paraview.org</a></font>
</div><p><font size="1" face="sans-serif">08/02/2010 17:32</font>
</p></td><td width="59%">
<table width="100%">
<tbody><tr valign="top">
<td>
<div align="right"><font size="1" face="sans-serif">A</font></div>
</td><td><font size="1" face="sans-serif"><a href="mailto:utkarsh.ayachit@kitware.com" target="_blank">utkarsh.ayachit@kitware.com</a>, <a href="mailto:paraview-developers@paraview.org" target="_blank">paraview-developers@paraview.org</a></font>
</td></tr><tr valign="top">
<td>
<div align="right"><font size="1" face="sans-serif">cc</font></div><div><div></div><div class="h5">
</div></div></td><td>
</td></tr><tr valign="top">
<td>
<div align="right"><font size="1" face="sans-serif">Objet</font></div>
</td><td><font size="1" face="sans-serif">Re: [Paraview-developers] Requiring
Qt 4.6 for ParaView 3.8</font></td></tr></tbody></table>
<br>
<table>
<tbody><tr valign="top">
<td>
</td><td></td></tr></tbody></table>
<br></td></tr></tbody></table><div><div></div><div class="h5">
<br>
<br>
<br><font size="2" face="Calibri">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?<br>
<br>
-Ken<br>
<br>
<br>
On 2/8/10 8:21 AM, &quot;Utkarsh Ayachit&quot; &lt;</font><a href="http://utkarsh.ayachit@kitware.com" target="_blank"><font size="2" color="blue" face="Calibri"><u>utkarsh.ayachit@kitware.com</u></font></a><font size="2" face="Calibri">&gt;
wrote:<br>
</font>
<br><font size="2" face="Calibri">Those are indeed good and valid points.
We were discussing a possible policy and here&#39;s what we have. What does
everybody think?<br>
<br>
* 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 &lt;= the official Qt version) depending
on whether we end up using some latest Qt functionality  provided
by the officially supported release.<br>
<br>
* Let Qt 4.6 be an exception, since Qt 4.6 is required to build on Snow
Leopard and it&#39;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)<br>
<br>
* 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.<br>
<br>
* Any user-interface related issues for any Qt version, but the official
version may not be addressed.<br>
<br>
* We&#39;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.<br>
<br>
* After two consecutive major releases (not patch releases) have stuck
with the same QT version and it&#39;s time to upgrade to a newer Qt version,
we&#39;ll pick the latest Qt version released at least 3 months prior to the
release.<br>
<br>
How does that sound? If it&#39;s acceptable, I can post it to the Wiki as the
official policy for Qt version updating.<br>
<br>
Utkarsh<br>
<br>
<br>
On Mon, Feb 8, 2010 at 3:32 AM, Stephane PLOIX &lt;</font><a href="http://stephane.ploix@edf.fr" target="_blank"><font size="2" color="blue" face="Calibri"><u>stephane.ploix@edf.fr</u></font></a><font size="2" face="Calibri">&gt;
wrote:</font>
<br><font size="2" face="Calibri"><br>
Hi, <br>
<br>
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. <br>
<br>
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. <br>
<br>
Some possible policy would be : <br>
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 <br>
or <br>
each stable version of ParaView will support both the lastest stable version
of Qt and the previous one <br>
<br>
or whatever, but please make it a public policy so that we know what to
expect. <br>
<br>
Best <br>
Stephane<br>
<br>
<br>
<br>
</font><font size="2" color="blue" face="Calibri"><b><u><br>
</u></b></font><a href="http://berk.geveci@kitware.com" target="_blank"><font size="2" color="blue" face="Calibri"><b><u>berk.geveci@kitware.com</u></b></font></a><font size="2" face="Calibri">
</font><font size="2" face="Calibri"><br>
Envoyé par : </font><a href="http://paraview-developers-bounces@paraview.org" target="_blank"><font size="2" color="blue" face="Calibri"><u>paraview-developers-bounces@paraview.org</u></font></a><font size="2" face="Calibri">
</font><font size="2" face="Calibri">07/02/2010 21:48</font><font size="2" face="Calibri">
</font>
<div align="right">
<p><font size="2" face="Calibri">A </font></p></div>
<p><a href="http://burlen.loring@gmail.com" target="_blank"><font size="2" color="blue" face="Calibri"><u>burlen.loring@gmail.com</u></font></a><font size="2" face="Calibri">
</font>
</p><div align="right">
<p><font size="2" face="Calibri">cc </font></p></div>
<p><a href="http://paraview-developers@paraview.org" target="_blank"><font size="2" color="blue" face="Calibri"><u>paraview-developers@paraview.org</u></font></a><font size="2" face="Calibri">
</font>
</p><div align="right">
<p><font size="2" face="Calibri">Objet </font></p></div>
<p><font size="2" face="Calibri">Re: [Paraview-developers] Requiring Qt 4.6
for ParaView 3.8</font><font size="2" face="Calibri"> <br>
<br>
<br>
<br>
</font><font size="4" face="Calibri"><br>
I wouldn&#39;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&#39;t run into Qt specific
bugs too often anyway. I defer to Utkarsh though.<br>
<br>
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&#39;t want to have an official rule about supporting
more than 1 version.<br>
<br>
-berk<br>
</font><font size="2" face="Calibri"><br>
</font><font size="4" face="Calibri"><br>
On Sun, Feb 7, 2010 at 3:08 PM, burlen &lt;</font><a href="http://burlen.loring@gmail.com" target="_blank"><font size="4" color="blue" face="Calibri"><u>burlen.loring@gmail.com</u></font></a><font size="2" face="Calibri">
&lt;</font><a href="mailto:burlen.loring@gmail.com" target="_blank"><font size="2" color="blue" face="Calibri"><u>mailto:burlen.loring@gmail.com</u></font></a><font size="2" face="Calibri">&gt;
</font><font size="4" face="Calibri">&gt; wrote:</font><font size="2" face="Calibri">
</font><font size="4" face="Calibri"><br>
Will this mean that PV won&#39;t build with any thing less than Qt 4.6?<br>
I wonder if it would make sense to have a small range of supported versions
rather than a single one?<br>
<br>
It&#39;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&#39;s packages. eg. Kubuntu 9.10 reports qt version 4.5.2. KUbuntu 8.04.4
LTS reports qt version 4.3.4.<br>
<br>