[Development] Removal of Non-deprecated API Elements in v6.6.0

[Volker Hilsheimer]

> On 19 Oct 2023, at 15:55, Phil Thompson via Development <development at qt-project.org> wrote:
> 
> On 19/10/2023 12:07, Giuseppe D'Angelo via Development wrote:
>> On 19/10/2023 12:07, Phil Thompson via Development wrote:
>>> Up until v6.6 upgrading to a new version was relatively low risk but this will just encourage people to stay on older versions. Is this a mistake or a change in policy?
>> There is actually a policy document that says that certain source
>> breaks are acceptable, especially the ones that prevent mistakes from
>> users:
>> https://contribute.qt-project.org/quips/6
>> I'm not really sure about the real-world impact of the change in
>> question, but there's an argument that this fits the QUIP-6 bill:
>> * if you have a non-const QSqlRecord object, you can keep calling
>> boundValues(). You would still get a mutable reference to the bound
>> arguments -- that is, that is 100% API compatible.
>> * If you have a const QSqlRecord, and you're trying to mutate the
>> bound values, then your code rightfully stops compiling, as you're not
>> supposed to do that. You can fix this in a way that works with Qt
>> before and after 6.6. So, you should do that.
>> Granted, each source-incompatible change disrupts _someone_ _somehow_.
>> I'm not sure where to draw the line: "this has to wait 10 years for Qt
>> 7" vs. "we should be changing this now, as we're making users a
>> disservice with a suboptimal/dangerous/misleading API" are both valid
>> arguments, but it's not a binary choice, it's much more of a gradient.
>> For this specific change, it's also interesting that it landed after
>> 6.5, giving people plenty of time to adapt.
>> My 2 c,
> 
> As I said I completely understand the reason for the change. QUIP-6 dates back to 2017 and the function itself dates back to 2005, so why now? Why not deprecate now and remove in v6.7?

I happened to look at the API because Christian applied some much needed TLC to Qt Sql, and we got a new Qt Sql driver contribution as well.

Deprecating it wouldn’t have been possible because we couldn’t have added a replacement API that would have been unambiguous, without coming up with a new function name. So you would have gotten the deprecation warning without a sensible way to fix your code.

> Also, can anybody point me to the ChangeLog for v6.6? (I want to find the entry with the [Potentially Source-Incompatible Changes] tag.)


The release notes with changes are here:

https://code.qt.io/cgit/qt/qtreleasenotes.git/about/qt/6.6.0/release-note.md

But, looking at the commit message of 3f72b0d5fc70d3cf7daa4badccd5a40fc8b0726a, I fear that you are catching me red-handed :(

Volker