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