QtCS2016 Deprecating APIs and Modules

• 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 version
    • 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