<font color="#550055">On 5/20/10, Felipe Crochik &lt;<a href="h/1tqlt06b4so7k/?v=b&amp;cs=wh&amp;to=felipe@crochik.com">felipe@crochik.com</a>&gt;
 wrote:<br>
&gt; Isn&#39;t the Qt version on PR 1.2 supposed to be 4.6.2 (the same we 
have on<br>
&gt; qt4-maemo5 and scratchbox right now)? I can&#39;t remember where I read
 this but<br>
<br>
</font>No way of knowing until PR1.2 actually hits the streets. The 
version<br>
in the SDK *is* newer than the libqt4-maemo5 one (note - it is the<br>
same base qt version, 4.6.2, but contains additional fixes/changes).<br>
Note that the PR might touch on other things, too - for example the<br>
4.6 on PR1.1 does not support autorotation, has hildon banner coloring<br>
issues, etc. So there are things that work or look differently even<br>
with the same Qt version.<br>
<font color="#550055"><br>
&gt; package but I would feel better if it was not as simple as 
submitting a new<br>
&gt; package with the same name and higher version. Maybe a consent from
 the<br>
&gt; maintainer or at least a &quot;put package on hold&quot; for few days waiting
 for a<br>
&gt; reply (or lack of) from the maintainer to an email sent 
automatically from<br>
&gt; maemo informing of the change. As now, It all can happen too 
quickly, in<br>
&gt; less than a day someone can submit a package and this package will 
be<br>
&gt; available to the users that have the development catalog. Just my 
paranoid<br>
&gt; self talking... As the community grows it may become more 
important.<br>
<br>
</font>I will talk about this to <a href="http://maemo.org/" target="_blank">maemo.org</a> people to see what the options are.<br>
<font color="#550055"><br>
&gt; The issue is not developing for an upcoming version. We will always
 have the<br>
&gt; scenario where there is a stable/official version and a upcoming 
one. Right<br>
&gt; now we have the qt4-core (4.5) and the qt4-maemo5 (4.6) in two 
different<br>
&gt; folders... Everything would be fine if the qt packages included 
with pr1.2<br>
&gt; were the qt4-maemo5 once out they would simply replace the &quot;beta&quot; 
ones<br>
&gt;<br>
&gt; I may be too naive but I think all this could be much simpler if we
 just had<br>
&gt; each official/major release of qt as a different package and 
installed to a<br>
&gt; different folder. Developers would be able to control the 
application<br>
&gt; dependencies. In fact that is exactly what I think my suggestion 
would do<br>
&gt; now.<br>
<br>
</font>Now we&#39;re gettingto the crux of the matter. The choice is not to<br>
support all versions of Qt simultaneously, but to have a single base<br>
version for each PR, and have this version on the NAND for speed<br>
reasons IIUC (plus integration issues as mentioned above) - and also<br>
to lower memory footprint, having GTK+ and Qt simultanously is<br>
stressful enough, having multiple versions of Qt in memory would make<br>
things even worse. So you won&#39;t have Qt4.5 on PR1.2, no Qt4.6 in the<br>
PR that will hopefully bring us Qt4.7, etc. The devel version is there<br>
just for, well, development and testing. As you can see this<br>
significantly lowers our <a href="http://maemo.org/" target="_blank">maemo.org</a>
 maneuvering space, too...<br>
<br>
Best regards,<br>
<font color="#888888">Attila</font><br>