[Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

Turunen Tuukka tuukka.turunen at theqtcompany.com
Thu Feb 19 17:21:19 CET 2015

> Lähettäjä: development-bounces+tuukka.turunen=theqtcompany.com at qt-project.org <development-bounces+tuukka.turunen=theqtcompany.com at qt-
> project.org> käyttäjän  puolestaRafael Roquetto <rafael.roquetto at kdab.com>
> Lähetetty: 19. helmikuuta 2015 17:03
> Vastaanottaja: Björn Breitmeyer
> Kopio: development at qt-project.org
> Aihe: Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
> On Thu, Feb 19, 2015 at 03:11:05PM +0100, Björn Breitmeyer wrote:
> <snip>
> > So long point short, i would like to dicuss this for a move to Qt6 because of
> > this and the points Andre mentioned already.
> +1

I think we should be able to address deprecation of old platform and compiler version also during the lifespan of Qt 5.x. I also do not think that time is yet right to make Qt 6, even though we are approaching the final Qt 4 releases :)

In Qt 5.5 we are dropping quite many older platform and compiler versions in order to be able to support new, so doing same in Qt 5.6 is completely reasonable to consider. 

Stating this, I am not yet taking stand whether we need to go "all-in" with C++11 in Qt 5.6, but we should at least properly consider the pros and cons. We already see that Qt WebEngine benefits from newer compilers and there are also other things to be gained by being able to better leveraging capabilities provided by C++11. 

What comes to supporting older compilers and OS versions, that is of course a significant item to consider as well. The typical options there are to support only a subset of Qt functionality in these platforms as well as case by case leveraging back porting to bring features from new Qt versions on top of an older one. One extreme approach is also to make a special version of Qt for these platforms, if the need is big enough. And a rather commonly used approach is to have an extended support agreement to cover the needed product lifespan, therefore reducing the need of moving to a new version.



More information about the Development mailing list