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
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
