[Development] Mandatory version numbers in qml imports (Re: (Harmattan) Qt Quick Components & Qt 5

Ville M. Vainio vivainio at gmail.com
Sat Jun 2 10:32:29 CEST 2012


Fwiw, I think it's just the matter of not having a champion that dislikes
the mandatory version numbering with enough passion to drive a language
change through.

Even if this is considered a misfeature by many, it sort of works, so
arguing that it needs to be fixed for qt 5.0 already is hard (as there is
other high priority work)
 On May 31, 2012 1:08 PM, <morten.sorvig at nokia.com> wrote:

>
> On May 31, 2012, at 10:53 AM, ext Simon Hausmann wrote:
>
> > On Thursday, May 31, 2012 11:47:23 AM ext Laszlo Papp wrote:
> >>> Please re-use the existing port of Qt Quick Components to Qt 5 before
> >>> starting a new effort.
> >>
> >> It is nice to have a branch, but why QtQuick 1.1 usages all around ?
> >
> > Because we wanted to keep the diff to master as small as possible, hence
> the
> > define/macro hacks. A smaller diff in turn makes it easier to merge
> _from_
> > master.
>
>
> We're in the same situation with the desktop components, wanting to
> minimize diff between the Qt 4 and 5 branches. I was even looking at a
> qmake hack to bump the import version. How did this work out in practice
> for the components project?
>
> The fact that we are both working around the versioned imports is
> interesting. So the question to the declarative devs become: Are there good
> reasons to not allow a versionless import?
>
> import QtQuick // Give me the highest version available and let me deal
> with the consequences
>
> This would be especially useful for "middleware" projects like components
> that should work on multiple  Qt Quick versions.
>
> Morten
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120602/703163c8/attachment.html>


More information about the Development mailing list