I think that maintaining the QtQuick1 in Qt5 will make people become accommodated with the old technology (those people who have apps relying on QtQuick1)<div>instead of adopting QtQuick 2 for their new applications (why spend time learning the new features of QtQuick2 if 1 is still working on Qt5?), as happened with qt3support.</div>

<div><br></div><div>Additionally, those people allocated to maintain QML1 could spend their time thinking about new features, things that were done erroneously in QML1 and make them better, improving QtQuick2.</div><div>
<br>
</div><div>As Alexis has pointed out, porting an application from QML1 to 2 isn't that painful.</div><div><br></div><div>That's my two cents.</div><div><br></div><div>Cheers<br><br><div class="gmail_quote">On Thu, Feb 16, 2012 at 11:42 AM, Thiago Macieira <span dir="ltr"><<a href="mailto:thiago.macieira@intel.com">thiago.macieira@intel.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On quinta-feira, 16 de fevereiro de <a href="tel:2012%2014.56.08" value="+12012145608">2012 14.56.08</a>, Stephen Kelly wrote:<br>


> On Thursday, February 16, 2012 14:50:32 Olivier Goffart wrote:<br>
> > On Thursday 16 February 2012 13:39:14 <a href="mailto:lars.knoll@nokia.com">lars.knoll@nokia.com</a> wrote:<br>
</div><div class="im">> > > Well, it's working for the moment, so the question is where the person<br>
> > > comes from that is willing to keep it alive. Since we'll keep BC after<br>
> > > 5.0, the work would mainly be to adjust to changes in private headers<br>
> > > and<br>
> > > internals.<br>
> ><br>
> > So if one wants to change the private header in qtbase while implementing<br>
> > a<br>
> > new feate, who is responsible to port QtQuick1? The one making the change,<br>
> > or the QtQuick1 maintainers?<br>
> ><br>
> > Because if it is the one making the change, then it becomes a burden for<br>
> > the developers in qtbase.<br>
><br>
> Isn't the same true in the QML2 stuff?<br>
<br>
</div>Yes, it is more or less the same still.<br>
<br>
It's a shared responsibility to fix those issues arising from changing of<br>
internal API. But the point is that there are people to share it with: the one<br>
who made the modification to the internal API in the first place and the person<br>
who understands the code that got broken.<br>
<br>
In the absence of either person, it's a nightmare. Which is why I really don't<br>
want a release *at all* unless there's someone to work with when changes to<br>
QtCore do happen. I don't want another ActiveQt on our hands, one that is used<br>
by lots of people and using a lot more internal API.<br>
<br>
Also note that there are plenty of strict-aliasing violations pointed out by<br>
the compiler today in the QtDeclarative 4.8 code. It's to be expected that new<br>
versions of GCC *will* cause breakages. Who will fix them?<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Thiago Macieira - thiago.macieira (AT) <a href="http://intel.com" target="_blank">intel.com</a><br>
  Software Architect - Intel Open Source Technology Center<br>
     Intel Sweden AB - Registration Number: 556189-6027<br>
     Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden<br>
</div></div><br>_______________________________________________<br>
Development mailing list<br>
<a href="mailto:Development@qt-project.org">Development@qt-project.org</a><br>
<a href="http://lists.qt-project.org/mailman/listinfo/development" target="_blank">http://lists.qt-project.org/mailman/listinfo/development</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Thiago de Barros Lacerda<div>OpenBossa - INdT</div><br>
</div>