[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