<font color="#550055">On 5/20/10, Felipe Crochik <<a href="h/1tqlt06b4so7k/?v=b&cs=wh&to=felipe@crochik.com">felipe@crochik.com</a>>
wrote:<br>
> Isn't the Qt version on PR 1.2 supposed to be 4.6.2 (the same we
have on<br>
> qt4-maemo5 and scratchbox right now)? I can'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>
> package but I would feel better if it was not as simple as
submitting a new<br>
> package with the same name and higher version. Maybe a consent from
the<br>
> maintainer or at least a "put package on hold" for few days waiting
for a<br>
> reply (or lack of) from the maintainer to an email sent
automatically from<br>
> maemo informing of the change. As now, It all can happen too
quickly, in<br>
> less than a day someone can submit a package and this package will
be<br>
> available to the users that have the development catalog. Just my
paranoid<br>
> 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>
> The issue is not developing for an upcoming version. We will always
have the<br>
> scenario where there is a stable/official version and a upcoming
one. Right<br>
> now we have the qt4-core (4.5) and the qt4-maemo5 (4.6) in two
different<br>
> folders... Everything would be fine if the qt packages included
with pr1.2<br>
> were the qt4-maemo5 once out they would simply replace the "beta"
ones<br>
><br>
> I may be too naive but I think all this could be much simpler if we
just had<br>
> each official/major release of qt as a different package and
installed to a<br>
> different folder. Developers would be able to control the
application<br>
> dependencies. In fact that is exactly what I think my suggestion
would do<br>
> now.<br>
<br>
</font>Now we'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'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>