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-boun...@qt-project.org> on behalf of Ville Voutilainen <ville.voutilai...@gmail.com> Sent: Tuesday, January 14, 2025 4:52 PM To: Ivan Solovev Cc: development@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@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@qt-project.org https://lists.qt-project.org/listinfo/development -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
