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

Giuseppe D'Angelo giuseppe.dangelo at kdab.com
Thu Oct 19 13:07:37 CEST 2023


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,

-- 
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4244 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.qt-project.org/pipermail/development/attachments/20231019/7f742b87/attachment.bin>


More information about the Development mailing list