On Tue, Jan 14, 2025 at 06:20:32AM +, Marc Mutz via Development wrote:
> Hi.
>
> At QtCS last year, we had a session on deprecations. From the summary at
> https://wiki.qt.io/QtCS2024_Deprecate, we've done (2)¹, but it seems
> like we have not come to grips with what (1) (deprecation is not
Qt 6.8 status
* Qt 6.8.2 preparations aren’t started yet; there has been dependency
update issues in qtdeclarative#6.8
* The target is to start branching from ‘6.8’ to ‘6.8.2’ immediately
after successful dependency update round in ‘6.8’
* The target is to freeze the release co
On Tuesday 14 January 2025 13:45:58 Pacific Standard Time Philippe wrote:
> > About Qt5Compat: there's still no replacement for QTextCodec, and I
> > don't understand why it was ever moved out of QtCore. As a consequence,
> > the first few Qt 6 releases weren't able to parse XML files with
> > shif
On Tuesday 14 January 2025 13:15:24 Pacific Standard Time Marc Mutz via
Development wrote:
> I see no reason, from a user perspective, to remove qt5support
> from Qt 7. Maybe we can make more fine-grained libraries libQTextCodec,
> libQRegExp, libQStringRef instead of using the "Qt N Compat" monik
> About Qt5Compat: there's still no replacement for QTextCodec, and I
> don't understand why it was ever moved out of QtCore. As a consequence,
> the first few Qt 6 releases weren't able to parse XML files with
> shift-jis encoding, a Qt 5 regression, still unfixed, except for libicu
> builds.
On 14.01.25 14:50, Volker Hilsheimer wrote:
> None of this implies that “Qt 7 will be source compatible with Qt 6”, or
> results in the automatism that Qt5Compat (or QtCharts, DataViz3D)
> continue to be included and maintained in Qt 7. Some things will stay,
> some won’t. We now have more ways t
On Tuesday 14 January 2025 08:46:40 Pacific Standard Time Jaroslaw Kobus via
Development wrote:
> 2. APIs that we want to only deprecate. All agrees on it, no one complains.
I think we need a timer on this. Most APIs that have been deprecated for N
number of years will be removed in the next rel
I think aiming for identifying deprecations like:
1. APIs that we are sure we want to deprecate and remove. All agrees on it, no
one complains.
2. APIs that we want to only deprecate. All agrees on it, no one complains.
3. Everything in between 1 and 2. We only know it deserves deprecation (which
On Tue, 14 Jan 2025 at 11:13, Ivan Solovev via Development
wrote:
> I tried to start a similar discussion in October [0], but there was no real
> conclusion apart from "let's decide on a case-by-case basis".
>
> My idea was that we can at least use the new to-be-removed approach on the
> APIs that
We decided in Würzburg that deprecation doesn’t imply removal in the next major
version, and that a new macro (as added by Ivan) gives us the ability to make
our intentions explicit at time of deprecation.
We might learn things between time of deprecation and the next major release
that change
Hi.
I tried to start a similar discussion in October [0], but there was no real
conclusion apart from "let's decide on a case-by-case basis".
My idea was that we can at least use the new to-be-removed approach on the
APIs that we consider wrong or dangerous. But the reality is that we cannot
agre
11 matches
Mail list logo
