[Development] QML and Qt Quick versioning of our modules

[Robin Burchell]

On Thu, Dec 7, 2017, at 02:53 PM, Frederik Gladhorn wrote:
> I've lately been discussing with a few people in The Qt Company about our 
> versioning.

Thanks for taking the initiative Frederik!

> And a general confusion around which version does what.
> Since we so far don't keep copies of old functions around (as far as I'm
> aware at least), I don't think there's a huge value in the versioning system in
> the first place.
> It only gives one important guarantee: if you added a property/type/name
> and 
> import a defined version, you don't suddenly get conflicts because we
> introduced 
> the same name.

There is an additional added benefit: if you are targetting a system
other than the one you are developing on now, you can set your import
version appropriately, and you won't be able to use any properties/etc
that were added later on than your target system. This is pretty good
for working on a "product" while not messing around with your
system-installed Qt, though I'll admit it's probably not a massive one.

I have wanted to be able to somehow get information about what version
was imported in the past, but it's not straightforward to see how to
accomplish that. It would then be useful for introducing changes in
behaviour that can then be explicitly opted into, though, without
needing to necessarily wait for a major version.

> Some modules started to copy the Qt version, e.g. Multimedia, that's
> pretty easy to remember and a good start in my opinion.

Agreed. The only caveat here is that it would prevent a repeat of
QtQuickControls 1->2: if you copy the major version from Qt, you can't
replace the whole implementation without giving it a new import, or
waiting for a new Qt release. I see this as a benefit in some ways: I've
heard of a lot of people who were (or are) confused by this, as the two
do offer some functionality that differs.

> 1) sync minor versions to Qt release version:
> For Qt 5.11, we would provide QtQuick.Controls 2.11
> This way, the challenge for the user is only to find out if it's version
> 1, 2 
> or 5.

Seems like a good idea.

> 2) Make the minor version import optional and we pick the lastest. This
> should 
> be optional to prevent the name clashes described above and shifts the
> risk to 
> the user.
> In practice I'd expect this to be pretty safe.
> import QtQuick.Controls 2 would then give the latest version available.

I'm inclined to prefer we don't do this, but I don't feel too strongly
about it, either - at least not as long as revisioning is as weak as it
is.

> 3) Make even the major version optional and we'd pick up the latest
> version.
> import QtQuick.Controls would give version 2.11 with Qt 5.11.

As well as preventing a QtQuickControls 1 -> QtQuickControls 2
transition again, this would also impact a hypothetical Qt 5 -> Qt 6
transition: QtQuick 6 (let's say) may well have behaviour changes in
some form over QtQuick 2. If we don't require versioning at all, then
suddenly, code that may not be able to work with that will be forced to
use it. Making the minor version optional doesn't seem to have many
caveats, but the major version is a bit more limiting and scary, given
we don't have a linker to help ensure we're using the right
dependencies...

> Luckily we now have qmlRegisterModule(QT_VERSION_MAJOR, QT_VERSION_MINOR)
> to help registering the current versions already.

Yep, this is good :)

Another potentially interesting idea that came to me while thinking
about this just now: what about implicit imports (versioned), added in
the qmldir file? Such that an: "import QtQuick 2.10" in the qmldir
applied to everything in an import that don't specify an implicit
version themselves. That would reduce clutter for anything which
actually has a qmldir (which tend to be most larger more complex
things), maybe that's good enough? Then, an application template could
use that out of the box, too. I don't know offhand how hard this would
be, but I don't think it would be too difficult.

-- 
  Robin Burchell
  robin at crimson.no