[Development] On deprecated APIs

[Marc Mutz]

Hi,

My porting guide for Q_FOREACH -> C++11 ranged for has created the expected 
outcry from users.

I think some of the FUD comes from the fact that deprecation in 5.x usually 
means that the API is gone in Qt 6.0.

I'd therefore like to propose a new contract with our users:

The Qt Project:
- continues to deprecate API it wants gone
- maintains deprecated Qt N.x API until Qt (N+1).0.
- does *not* remove deprecated N.x API anymore come (N+1).0
- does also *not* maintain deprecated N.x API after the initial (N+1).0.0
  release
  * (ie. N+1).y CI runs with API deprecated in N.x (or earlier) disabled
  * also means Qt does the work of making sure deprecated API is turned
    all-inline before a .0.0 release to maintain BC.

In return, the Qt users:
- stop insisting on -Wdeprecated-clean builds without investing time of their
  own into updating their sources
- provide patches to maintain deprecated APIs we no longer maintain

In return, the Qt Project:
- pledges to take those patches in without hackling about "but it's
  deprecated..."

This allows us to continue to mark API deprecated, so new users have guidance 
on what API to avoid, while giving peace of mind to users of exisiting API 
that their investment is protected, as long as they're willing to participate 
in maintenance.

I believe this is fair and beneficial for both sides. I don't know how far 
this will carry us (technically and socially), but maybe we can just try it in 
the Qt 5 -> 6 transition?

I won't be able to come to QtCon this year, either, but feel free to take the 
opportunity to discuss this there.

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - Qt, C++ and OpenGL Experts