t bit of useful info. There's a benefit of
having all the docs in a self-contained
set as well.
-Topi
From: Development on behalf of Paul
Wicking via Development
Sent: Friday, September 15, 2023 11:25 AM
To: Edward Welbourne
Cc: development@qt-project.org
S
On 15 Sep 2023, at 10:44, Edward Welbourne via Development
wrote:
On 9/15/23 09:36, Kai Köhne via Development wrote:
The methods are formally marked as deprecated for Qt 6.10. But the
methods are already in the '-obsolete' page for Qt 6.6, which leaves
the API in a weird in-between state.
Chr
On 9/15/23 09:36, Kai Köhne via Development wrote:
>> The methods are formally marked as deprecated for Qt 6.10. But the
>> methods are already in the '-obsolete' page for Qt 6.6, which leaves
>> the API in a weird in-between state.
Christian Kandeler (15 September 2023 10:31) wrote:
> Radical ide
On 9/15/23 09:36, Kai Köhne via Development wrote:
The methods are formally marked as deprecated for Qt 6.10. But the methods are
already in the '-obsolete' page for Qt 6.6, which leaves the API in a weird
in-between state.
Radical idea: Treat all deprecated functions as if they didn't exist,
Hi,
> I see two fixes for this;
> - Keep the documentation API fix separate from the header file fix, and only
> merge it when Qt 6.9 got branched.
> This requires 'someone' to follow up on these things, though, more than a
> year after the deprecation decision has been made.
This approach will
Kai Köhne (15 September 2023 09:36) wrote:
> I see why this 'conservative' approach is beneficial. Projects like Qt
> Creator tend to support multiple Qt versions, and immediately
> deprecating an old API in the same version the replacement API got
> added makes this hard to handle.
Note that QT_W
