[Development] Notes on "Deprecating APIs & Modules" session @ QCS 2016

Thiago Macieira thiago.macieira at intel.com
Sun Sep 4 14:05:16 CEST 2016


* Deprecating API
** Configuring them out
** Use QT_DEPRECATED_X to include a short description (if possible)
*** Serious deprecations (any use is a flaw) should use Q_DECL_DEPRECATED_X
** Advertise the feature
** Should we increase the QT_DEPRECATED_SINCE value?
*** Creator's project wizard should include QT_DEPRECATED_SINCE to current 
*** qmake -project
** Change Qt Creator to increase QT_DEPRECATED_SINCE
* Deprecating modules
** Policy: will not remove the module before 6.0 if we can; if we have to, it 
will be a soft-removal
** qmake should warn
** Security policy: most likely not get fixes
** How long must we support them? (non-removed)
*** We fix security issues, P0 and P1
* Removing modules
** Soft-removal: not shipped, but still guaranteed to compile until 6.0
** We fix only P0 issues
** No longer commercially supported
** Doesn't stop the release, but fix comes soon after
*** fix should be in the works for the release to happen
** qt5.git should not build them; build should happen on top of qt5.git
*** We should produce weekend updates that verify that they still compile 
(post to dev)
*** For modules that run unit tests when staging patches, unit tests too

== Separate discussion on qttools during cross-compilation ==
* host tools should be compiled outside of qt5.git
* no need for wide compiler support
* needs to be had separately
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

More information about the Development mailing list