[Development] QTCS2019 Notes from QtQml session
dpurgin at gmail.com
Fri Nov 22 07:33:38 CET 2019
thanks for clarifying. You're absolutely right, no other language supports
importing different versions of dependencies but I think it is a great
feature of QML that helps a lot in maintaining the old code. Would be sad
to see it gone in QML 3.
PS I'm forwarding this email to the mailing list again, apparently I didn't
manage to this right in the first place
On Thu, Nov 21, 2019 at 4:23 PM Ulf Hermann <ulf.hermann at qt.io> wrote:
> > Suppose it's been a while, and your customer has used this library in
> > their code in 100 QML files. Now you enhance/refactor your library and
> > you decide that the name `popupSource` was not really good because it
> > clashes with a new component, so you change it to `componentSource` in
> > the new version:
> This is a compatibility breaking change. There is no way a QML program
> written against the old version of your library will work with the new
> version of your library without modification. You should use a new major
> version for this. The minor versions were intended for non-breaking
> changes, specifically for adding properties, methods, enums. If you
> avoid unqualified lookup you can do these things without special
> consideration in the customers of your library, as they won't see the
> new constructs unless they explicitly look them up.
> We might also remove the major version, though. The cleanest way to
> upgrade your library's clients to a new version of your library is not
> providing both versions of the QML code in one version of your library,
> but rather releasing a completely new library with only new code, and
> adapting your client code to use that. Currently you can do that on a
> file-by-file basis, but allowing that was a mistake. You should port the
> client code at least on a module-by-module basis, so that you can use
> the same version of your dependencies in each file. No other language I
> know allows you to import different versions of a dependency in two
> files of the same module.
> You may need some migration strategy, like providing deprecated
> properties for a while in order to ease transition. This is pretty much
> the same as in C++, then.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Development