[Development] Deprecation/removal model going into Qt 6

[Stottlemyer, Brett (B.S.)]

On 6/1/19, 9:10 AM, "Development on behalf of Philippe" <development-bounces at qt-project.org on behalf of philwave at gmail.com> wrote:

    I second a recent quote from Lars Knoll :
    
    > Qt has always had a somewhat different philosophy. Make C++ easy to use,
    > no need to use Java. The fact is that 95% of the source code our users
    >write will not be performance critical. You don’t want to make the pay
    >the price of having a difficult to use API for those 95% of the code. 
    
    And I wish to add: the vast majority of Qt developers I have met, are
    not C++ wizards.
    
Thanks Philippe/Lars, and Giuseppe for starting this separate thread.

This discussion reminds me of Python 2 vs. Python 3, and I think there are some important lessons to consider from Python.  I'm one of those holdouts that had a lot of Python 2 code and saw no compelling reason to move to Python 3.  Until recently I didn't fully understand the reasons for the incompatible changes, so it looked like a bunch of (error prone) work with no clear value.  While enum support was a nice to have, there were ways to add that to python 2.  It was Python 2 nearing deprecation and some recent features (among them type safety) in Python 3 that got me to finally convert code this year.

Diving into that conversion led me to a very helpful blog (from one of the core developers, Nick Coghlan) on why the changes were made in the first place: http://python-notes.curiousefficiency.org/en/latest/python3/questions_and_answers.html#tl-dr-version.  It is a lengthy post, so let me quote a few sections I think are particularly relevant:

"[W]e did not see any other way to ensure Python remained a viable development platform as developer communities grow in locations where English is not the primary spoken language."
"It is my perspective that the web and GUI developers have the right idea: dealing with Unicode text correctly is not optional in the modern world. In large part, the Python 3 redesign involved taking Unicode handling principles elaborated in those parts of the community and building them into the core design of the language."
^^^ This is the fundamental reason for the compatibility break.  Three sentences!

"Python 3 introduced backwards incompatible changes that more obviously helped future users of the language than they did current users, so existing users (especially library and framework developers) were being asked to devote time and effort to a transition that would cost them more in time and energy in the near term than it would save them for years to come."
^^^ This is one of the major reasons for slow adoption

There is a section titled "When did Python 3 become the obvious choice for new projects?"
"I put the date for this as the release of Python 3.5, in September 2015."
^^^ I believe this was the other major reason for slow adoption, a combination of two issues.  There needed to be compelling features to drive the transition, and frameworks people used (numpy, nltk, twisted, etc) were slow to become available.

I don't, at this point, have any idea what the right answer for Qt is.  But there are three factors I think we need to consider with the move to Qt 6.

1) I believe there needs to be an elevator pitch (i.e., 30 seconds or less to tell the story) of why Qt 6 is not compatible with Qt 5
It seems like this is something along the lines of "Changes in the C++ ecosystem, specifically the compiler features added into the standards for C++11, C++14, etc, duplicate functionality provided by Qt, but in a way officially supported (and optimized) by compilers.  Leveraging these features is necessary for Qt going forward, but requires incompatible changes to our APIs."  I know people will disagree with the wording, if not the sentiment, here.  The point is the importance of a concise reason.

2) There needs to be a reason to upgrade
I remember Lars saying at QtCS last year that Qt 6 should be the easiest upgrade.  It wouldn't include many new features, instead focusing on fixing the elements that couldn't be addressed without breaking compatibility; deprecation warnings in Qt 5.x would help, i.e., upgrade to 5.15, address the deprecation warnings, and viola - ready for Qt6.

While I understand the ease part of that plan (and agreed it was the right approach at the time), "Upgrade to Qt 6: you may notice some performance improvements" is not a great motivator.

If there isn't a clear benefit yet, then maybe something like "This was a required change in Qt, to leverage the benefits of C++11, C++14 and C++17, reduce the maintenance burden on Qt, and allow Qt to focus on bringing value to customers in other areas.  New features will be coming once we've completed this transition."  Side note: is it fair to say the additions in C++17, C++20, etc are becoming more esoteric, in the sense that incorporation into Qt would be less likely to be incompatible?  Or should people fear Qt 7 is not too far out?

3) Be careful of "death by a thousand papercuts"
One of the changes in Python 3 that really bugged me was converting `print` into a function.  I have to find every print instance and convert it?  Why?  It doesn't add any value to my code.  How many people will find switching from qmake to cmake that pain point that delays moving to Qt6?

There is an impact to the argument "we are breaking compatibility, we should get all of the changes in now."  Any one change could be particularly painful for any specific user and cause them to hesitate in moving to Qt 6.  I think this has been touched on over the last few days with some discussion of more incremental API breaks.  While I imagine the difficulty in maintaining compatibility in Qt is a pain point for developers of Qt itself, I do think API stability is one of the major selling points of Qt that has kept Qt growing for over 20 years.

Thanks for your consideration, I just want to make sure the overarching messages don't get lost in the detailed discussion.

Regards,
Brett