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

[Phil Thompson]

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?

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

Phil