On Thu, 18 Aug 2011 22:09:59 ext Artur Souza (MoRpHeUz) wrote: > On Wed, Aug 17, 2011 at 10:42 PM, Alan Alpert <[email protected]> wrote: > > If we call minor releases patch releases then we're getting the > > terminology mixed up. Minor releases a.B.c and patch releases a.b.C are > > quite separate. > > Yes, sorry. I was refering to patch releases. > > > Because QML is declarative, brand new, and has a versioning system > > designed to let it grow, it will grow faster than Qt (at least it has, > > historically speaking). So if we want to have useful version numbers it > > will need a different version number to Qt, especially since QML import > > statements don't have a patch release number (they ought to be only at > > the level of implementation details anyways and QML enforces this - so > > we can't just add features in patch releases like Qt does :P ). > > [...snippet...] > > I understand your points. But it was special in Qt 4.x. QML was right > at the beginning of its life and because of this there were a lot of > new features that you wanted to release as soon as possible. > > But for Qt 5, and QML being at the core of it I think we should plan a > little bit more the releases. If QML had a so urgent need of releasing > something, Qt as a project should manage that and release a minor > version (not a *patch* release).
If you're saying that Qt 5 releases can move at QML's pace, that would work as well. It would mean that Qt 5 minor releases will have a tighter schedule than Qt 4 minor releases, something that is not yet certain to be feasible. > Lighthouse is also very new and other technologies in Qt were also > very new when we had Qt 4.0 and this was not an excuse for then to not > wait the release of a minor version and start releasing stuff in patch > versions. Lighthouse's exposed API is minuscule compared to the QML API. Most C++ APIs are like that, where they have a more focused usecase and limited public API. The QML APIs have the usecase of all UI elements, and so have an explosion of public API larger than the average C++ feature. But the C++ API of QtDeclarative is restrained, so there's a clear separation with bulging QML API allowing the two to progress differently. I'm saying that it's reasonable for it to behave different to lighthouse because it *is* very different to lighthouse. Lighthouse is a good example because it's another large, important, and unusual feature, but it still doesn't have anything like the public API of the QtQuick 1 module. > From my point of view, if we can wait a minor release for everything > else we can do the same for QML. QML is still very young compared to the other parts of Qt. I'm still not convinced that it doesn't move faster than the C++ API. I don't think Qt started slowing down until Qt 3, and I'd expect the same for QtQuick. So just because we're at QtQuick 2 doesn't mean that we've completed the rapid growth phase. -- Alan Alpert Senior Engineer Nokia, Qt Development Frameworks _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
