[Development] QtCS 2024 session on deprecations: what did we actually agree on?

[Jaroslaw Kobus]

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 all agree on), but we can't agree whether it should be ultimately removed or not. Possible further actions (after the deprecation):
- Gather the feedback from users? What are their reactions on possible removal? We evaluate a feedback and move it to 1 or 2.
- We conclude / gather a strong evidence either for 1 or for 2 and we move it there.

might be a possible way to go. At least we have clear rules for 1 and 2.

Each of 1, 2 and 3 should have a different deprecation marker.

Jarek

________________________________________
From: Development <development-bounces at qt-project.org> on behalf of Ville Voutilainen <ville.voutilainen at gmail.com>
Sent: Tuesday, January 14, 2025 4:52 PM
To: Ivan Solovev
Cc: development at qt-project.org
Subject: Re: [Development] QtCS 2024 session on deprecations: what did we actually agree on?

On Tue, 14 Jan 2025 at 11:13, Ivan Solovev via Development
<development at qt-project.org> 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 consider wrong or dangerous. But the reality is that we cannot
> agree even on that (consider the discussions about QScopedPointer::take()
> in [1]).
>
> It all makes me think that we really need to agree on some policy.

I wonder what such a policy would help. Let me explain what I mean by
my confusion:

1) suppose, hypothetically, that we have a policy "deprecated things
are removed in the next major version"
2) for some reason, we then say "except this thing here, for biz
reasons or otherwise"
3) someone might then say "no, the policy is to remove it", and be
pretty much ignored..
4) and then we end up discussing policy exceptions, quite like we
would discuss individual removals.

Drafting policies that predict the future is hard. And policies that
fail to predict the future tend to lose their
meaning due to there being so many policy exceptions.
--
Development mailing list
Development at qt-project.org
https://lists.qt-project.org/listinfo/development