On Wed, 17 Aug 2011 22:53:00 ext Artur Souza (MoRpHeUz) wrote: > On Tue, Aug 16, 2011 at 8:50 PM, Alan Alpert <[email protected]> wrote: > > The advantages of the other approach is that we can be honest about the > > version numbers. The major and minor version implications for Qt and QML > > have diverged slightly, especially in the patch releases. A patch > > release for Qt should not affect public C++ API, and this is entirely > > consistent with a new minor release of QML (which can add new QML API, > > the QML versioning system allows this to be safe). > > Besides not affecting public C++ API I also don't think it's a good > "behavior" to add features on a minor release. Minor releases are > meant to fix stuff of the major release, that's why we call it patch > releases :)
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. 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 ). > Right now it only happened in Qt 4.7.4 and at least for my customers > it caused a lot of confusion. If you don't think about Nokia (which > only has good reasons to do this because of weird situations), I can't > think about good reasons to add features on minor versions as > everybody else is also waiting for the major release to get their > features into Qt. Here some the good reasons why QML should be allowed to grow quickly, and currently that means faster than the C++ API. Note that if the C++ minor versions were quick then we wouldn't have a problem with this, but as they are not we can't stay shackled to the same version. I understand that it's confusing for customers, but that cost is lesser than the cost of weakening QML. 1. QML is much, much newer than the rest of Qt. As it emerges from its chrysalis, it naturally requires a faster release cycle. Compare the speed of Qt 1 and 2 to the speed of Qt 4. We don't want to damage the breadth and quality of the Qt C++ APIs now that they have matured, but nor do we want to retard the development of QML. 2. QML versions are safer to upgrade. Half the point of the QML versioning system was to avoid the compatibility requirements that the Qt versions labor under. A new QML minor version won't break things and introduces less risk of regressions, because all new symbols are namespaced to the new version. So we can increase the minor version faster and safer, and applications won't break from it. 3 (the minor point). As QML is declarative, we have a lot more that we need to do. We control the entire engine and language, not just providing choice APIs but almost everything that one can do in QML (without exposing your own classes to QML). To facilitate this, we have kept a narrow scope of C++ API made public for using the language and declarative engine. This C++ API can be worked on at the Qt speed, but the QML API is vast and still should be much more. We have a lot of stuff to do that is an implementation detail for the C++ API, but a behavior change for the QML API. So even within the QtDeclarative module alone, we have differing development speeds for the core C++ API and the expansive QML modules. -- Alan Alpert Senior Engineer Nokia, Qt Development Frameworks _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
