[Development] QML import versions

[Robin Burchell]

On Fri, Sep 18, 2015, at 08:15 PM, Nurmi J-P wrote:
> > I have some opposition to the idea because it entirely prevents us from
> > making changes if they are needed. An example of this came up just the
> > other day on IRC: Window{} has a number of major (or at least quite
> > irritating) flaws. A few of us were discussing whether/how it would be
> > possible to fix them in a QtQuick.Window 3.0, without breaking backwards
> > compatibility with older code, and without waiting for Qt 6.
> 
> I think it’s a reasonable trade-off. Qt has lived with this restriction
> for quite long. :)

I think the reason that the imports system evolved in this direction was
because it was considered to be too limiting, and in the case of QML,
not necessary because of the capability to provide backwards
compatibility. You can't easily use Qt 4 and Qt 5 in the same codebase,
you could use QtQuick.Window 2 and QtQuick.Window 3 in the same
codebase, theoretically.

> If this is about the Item-based Window, would it make sense to give a
> different name? Panel? Popup? There’s also something related in the works
> in Qt Quick Controls 2.

Without wanting to go too far off on a tangent here:

I personally think that a concept that maps to a Window deserves to be
called a Window. Definitely not Panel or Popup at least as both of those
have different meanings in windowing, and neither of them match on
desktop platforms (sure, on platforms *without* windows, it does).

> >> How often do we release new major versions of QML modules? I don't see why QML
> >> modules couldn't follow the same practices than the rest of Qt follows.
> > 
> > At present, we don't, but I think that's more down to the low amount of
> > activity happening outside the engine (at present) rather than the lack
> > of a _need_ to in some areas. Adopting this policy would mean there is
> > zero chance of these ever happening outside of major Qt releases, which
> > ties things to a much longer timeframe than "whenever we feel like
> > bumping the major version number".
> > 
> > To me, that feels like a pretty big loss, even if I can see the appeal
> > we get in having consistency.
> 
> Yeah, it’s a big limitation, but I’d vote for consistency for the sake of
> pleasant Qt Quick experience. It would also mean that we wouldn’t be able
> to release Qt Quick Controls 2.0 as is. We could release some parts of it
> under a different import, though.

> The QML version mess has been bothering me for a long time, and as I
> tried to illustrate in the initial email, it keeps getting worse every Qt
> release… :(
> 
> > It also means we're bumping version
> > numbers for the sake of bumping version numbers in cases where there
> > really aren't any (or at least many) changes, in the case of e.g.
> > Particles, which is less of an issue, but still an issue.
> 
> Is it any different to bumping the version of, say, QtXmlPatterns?

No, but one doesn't do something like "#include
<QtXmlPatterns/5.6/FooBar>" (unless one is using private API, in which
case it's all your fault, you're a horrible person, and you deserve
everything you get).

In other words, those version numbers are a lot more transparent to the
developer & end-user, unless they specifically rely on new
features/bugfixes. This is both a good thing (meaning that we have more
freedom to make changes), but a bad thing (due to potential
inconsistencies in how it's approached, and e.g. the massive smattering
of version numbers that we have now)

In QML, the version numbers are directly exposed to the developer. This
means that it would be a lot easier to, say, import QtQuick.Particles
5.7, and stop that application working on any prior version of Qt purely
because we decided to bump the import version, when there are no changes
in the module at all.

Maybe another solution towards this problem would be removing minor
versioning from our vocabulary altogether, and simply using a major
version number for imports:

import QtQuick 2
import QtQuick.Window 2

... and so on.

Functionality is always available (unversioned) in that import. Code
written for older versions will Just Work on newer versions (as it does
now). Code written for newer versions will Just Work on older versions,
unless it relies on newer features (as it does now, just with a
different error message: admittedly it might be a less descriptive one -
you'd get told that the type/property didn't exist, as opposed to module
version foobar is not available - but this is also the case with C++
usage now!).

Or am I missing some other value offered by minor version numbers?

We'd still have potential inconsistency with major version numbers, but
in my opinion, this is less of a problem, as at least in that case it's
usually a little more developer-evident when and why those change, and a
lot less frequent.