Going through the discussions and looking at our time schedule, here’s another proposal how we could do things (slightly different from what we discussed at QtCS):
* We make Qt 5.6 an LTS release * We already have of the current dev branch on pretty much all platforms supported in Qt 5.5 working in the new CI (exceptions in QNX 6.5). It’s mainly about some details now and flipping the switch. * We delay introducing hard dependencies to C++11 to Qt 5.7. This doesn’t come at a huge cost from an R&D perspective as the 5.6 feature freeze is in the beginning of August. So once everybody is back form summer vacations, we could start cleaning up our code base aggressively. * We could then have both WEC7 and WEC2013 (on VS2012) supported on 5.6. This would solve all problems for Windows Embedded and we could make VS2013 the compiler baseline for 5.7. * We’d still remove the deprecated modules from our Qt 5.6 release (maybe with the exception of Qt Script). That would give us a pretty good baseline to work with for the LTS release, we’d keep people on older compilers/OSes happy and we could move a lot more aggressively towards C++11 in the dev branch directly after summer vacations (from the beginning of August). Opinions? Cheers, Lars On 17/06/15 10:54, "André Somers" <an...@familiesomers.nl> wrote: >Giuseppe D'Angelo schreef op 17-6-2015 om 10:34: >> I would also push the "C++11 in our API" to 5.7 to minimise the risks. >> Cheers, >C++11 in our API was to be taken slowly anyway, according to the session >at QtCS. We would start with using it in the implementation to gain some >experience first. See notes from that session. > >André > >_______________________________________________ >Development mailing list >Development@qt-project.org >http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development