On Oct 10, 2012, at 7:46 PM, Thiago Macieira <thiago.macie...@intel.com> wrote: >> nterpreted as good reasons to have a 4.9 release > > Exceptions given on a case-by-case basis. > > The above is much more than adding a symbol as an artifact of a change. It's > whole new API and features. It should not go into 4.8.
I think we need to take a second look at the 4.8 submit policy. I'd like to make a special argument for allowing 33266, and then a general argument for allowing API additions to Qt 4 in response to platform changes. Qt 4 works well on retina displays. If you have't seen it, find someone with a Mac and ask to see Qt Creator in hidpi mode - either real or emulated. What is missing is features to handle raster graphics where you need to provide high-dpi artwork and in some cases be aware of the points/pixels distinction. This requires new API and fixes to Qt itself. These fixes are something we have ready since we're implementing them for Qt 5. Qt users are to a large degree using Qt 4 now. If you ask support they'll tell you porting from Qt/Carbon to Qt/Cocoa is a hot topic. The platform implementation in Qt 5 is a (another) rewrite, and we can not expect bug-for-bug compatibility in 5.0. The expected outcome is then that many Qt users will stay on Qt 4 in the near future. It would be quite counterproductive of us to hold back on good fixes that we already have developed due to a policy of not updating Qt 4. It gives the impression that we don't care about users and that we are not protecting the investments that has been made in writing code against the Qt API. In general, I think this is something we'll see again. Platforms change under our feet and we need to adapt. Apple and Microsoft do not put OS updates on hold because we are working on a major release. The fact that Qt often "lags" platform releases is a major point against using Qt and something we must get better at. A sensible solution is, in my opinion, to allow feature and API development in Qt 4 when the platform maintainers find it necessary. Morten _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
