[Development] On deprecated APIs

[André Somers]

Op 31/08/2016 om 09:38 schreef 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
>
Hi,

While I understand the idea, I think it is very risky. I think it will 
be hard to explain to users, and even harder to defend against 
complaints and negative sentiments from users when the functionality 
_does_ break. Not maintaining something any more will mean that probably 
at one point, it will break. Do we really want to ship Qt in a way that 
we know will break, and will accumulate more breaks as time goes by? How 
do you deal with features that not too many (capable) people care about, 
do you just let them rot?

I think asking the community to keep supporting certain features the 
project at large wants to deprecate without any support is not a fair 
deal for anyone. Would the people able to support such features into the 
future in fact already be likely contributing to the Qt project? 
Supporting a feature without the aid of CI is also quite a bit harder 
for any individual maintainer. In the case of Q_FOREACH: how would you 
maintain this without access to all the supported platforms and 
compilers? On the other hand: how do you as a user know which 
depreciated features are and which are not supported by the community? 
Doesn't that make Qt as a whole less reliable?

I would like to make a slightly different suggestion: let a deprecation 
be a reversible state. It could signify that the Qt project is no longer 
willing to maintain it, and it thus will go away, _unless_ somebody 
stands up to accept maintainership of said feature/class/whatever and 
promisses to keep it working before the removal takes place. It would 
then *not* be removed from CI, but it could be marked as "community 
supported" or something like that to signify it's continued support is 
not as certain as other parts of Qt. Also, Qt internally would not be 
allowed to depend on such community supported code any more. If nobody 
stands up to take maintainership, it will indeed be removed at the 
appropriate time.

BTW: A quick search on the ML archive did not turn up a discussion on 
the removal of Q_FOREACH. Would that not be required before marking it 
deprecated? I did find more of an announcement[1]. I also found a 
post[2] by you where you say:
> Try to port all your Q_FOREACH to range-for loops. You will be surprised how
> much digging is required if you don't always want to take the hit of taking a
> copy.
Isn't that essentially the contents user outcry you are refering to?

André

[1] http://lists.qt-project.org/pipermail/development/2016-May/025843.html
[2] 
http://lists.qt-project.org/pipermail/development/2015-December/024187.html

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160831/04afa4fa/attachment.html>