[Development] QML import versions

Olivier Goffart olivier at woboq.com
Thu Sep 24 08:19:34 CEST 2015


On Monday 21. September 2015 08:07:24 Nurmi J-P wrote:
> On Sep 21, 2015 7:48 AM, Olivier Goffart <olivier at woboq.com> wrote:
> > I've always found that tyhe revision system is broken by design.
> > (Because of the mainingless of the version number, because of the
> > inheriting, because it's of little use anyway for we always do behaviour
> > changes and the likelyhood of a name clash is not the worst)
> >
> > Here was my proposal:
> >
> > class QQuickImage {
> >    Q_CLASS_INFO("Qt.Module","QtQuick")
> >    Q_PROPERTY(int rating MEMBER m_rating NOTIFY ratingChanged SINCE 2.6)
> > public slots:
> >    Q_SINCE(2.6) void shareOnSocialMedia();
> > };
> >
> > The Q_SINCE could even be parsed by qdoc and be an alternative to the
> > \since
> 
> That would a massive improvement, but it boils down to the same problem. It
> can only be like that if Qt and QML version numbers match. We cannot
> sprinkle qtquick versions to the base classes in qtbase.
 

We could imagine that import would have dependencies
So that
"import QtQuick 2.7;" would imply "import Qt 5.7;"
(And "import QtQuick.Controls 1.4" could imply "import QtQuick 2.7")


Your "solution" to have all the minor version number of all modules the same 
as Qt would not work with third party libraries that have different releasing 
cycle.

(And remember that the whole reason behind modularisation and the different 
version number comes from the wish to release QtQuick with a different release 
cycle than Qt itself)

-- 
Olivier 

Woboq - Qt services and support - http://woboq.com - http://code.woboq.org



More information about the Development mailing list