>From: "[email protected]" <[email protected]> >To: [email protected] >Cc: [email protected] >Sent: Wednesday, September 14, 2011 5:42 PM >Subject: Re: [Qt5-feedback] Release configurations and API stability (Was: Re: >Moving examples to a separate module) > >On 09/14/11 at 09:41P, ext Stephen Kelly wrote: > >[...] > >> > This means that >> > eventually the release maintainer has the flexibility to decide if these >> > modules makes sense for their configuration. If not, they can drop it >> > from their release. >> >> What's this about? What is a release maintainers configuration? Why would a >> Qt module not be part of a release maintainers configuration? > >>From [1], > >"A (release) configuration is a detailed specification of an operating >system version, a tool chain version, a graphics system, and possibly >other dependencies. The supported configurations of Qt are defined by >what is used in the build bots." > >In order to meet the Qt5 release criteria, a release maintainer has to >just include Qt5 essential modules. In addition its really up to the >release maintainer to select the addons that makes sense for their >configuration. > >For e.g., in Qt5 desktop configuration, is makes sense to include >QWidgets as an addon module, but then there could be a configuration on >a different OS where it might not make sense. > >At that time, qtexamples module should not become an hinderance to that >release maintainer. > >[...] > >> > - We now create a dependency between the module maintainer of any module >> > and the qt-examples module maintainer. Every time some change to the >> > example which could be because of a number of reasons - API change, >> > improving the example for additional clarity etc., the change needs to >> > be pushed into qt-examples. >> >> After the 5.0 release there presumably won't be API changes. Doesn't this >> issue only apply to times when APIs are changing, which is presumably rarely >> between releases? > >That's the goal and hopefully there'll be minimal changes to the APIs in >modules that are a part of Qt Essentials. > >However, other Qt Modules might undergo API changes. So for those add-on >modules, the API compatibility promise could be different. It would >largely depend on the module maintainer. > >[1] >http://developer.qt.nokia.com/groups/qt_contributors_summit/wiki/Qt5ProductDefinition >
Please don't make Release Configurations overly complex in implementation. That is - there should only be a handful of release configurations: Windows Mac X11/Wayland/etc Embedded/General (QWS) Embedded/Symbian Embedded/MeeGo Each of these ought to be pretty straight forward and contain all modules by default; allowing developers to disable individual ones when they want just like in Qt4. The exception might be Embedded/Symbian and Embedded/MeeGo where QtWidgets might not be used as QtGraphicsWidget+QML is likely the priority and main use there; but even there it should probably be available for developers to enable if desired. It would only make things more difficult for people deciding which to use if you have to select from different flavors of Qt; as it is, the above can be problematic enough for Commercial Users - where X11/Mac/Windows while targetting different OS could simply be Qt Desktop instead. There is not reason to follow Microsoft's lead of splitting Windows into Windows Starter Edition, Windows Home Premium, Windows Professional/Business Edition, Windows Ultimate, and the other variants that I am missing and doing something similar with Qt as that is not useful for developers when it comes to a toolkit. $0.02 Ben _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
