[Development] Deprecation/removal model going into Qt 6
kshegunov at gmail.com
Mon Jun 3 02:21:28 CEST 2019
On Mon, Jun 3, 2019 at 2:10 AM Manuel Bergler <berglerma at gmail.com> wrote:
> Why should software be different?
It shouldn't, as already pointed out. That's why well behaved libraries try
to keep compatibility in some reasonable margins.
To throw one more stone here - are you willing to backport patches from
latter minor versions to former ones? When the API and ABI breaks often
that isn't very trivial, is it?
On Mon, Jun 3, 2019 at 2:47 AM Manuel Bergler <berglerma at gmail.com> wrote:
> a) Qt can never remove superseded APIs and classes (which is what
> you suggested previously) and will eventually collapse under its own
> weight, or
It can under the current model where API and ABI breaking may happen
between major versions, which I find rather reasonable.
> b) Distributors have to deal with the fact that some software
> doesn't port and have to ship every version of qt side-by-side, or
Like they do with boost? Which they don't, obviously.
It simply ain't going to happen they're not an infinite well of computer
and human time.
Also are you suggesting that all applications sync up theirs to your
release cycle? Or are the distros to do that?
If porting the application between minor versions takes more time than the
time to introduce a breaking change, then you're never going to port
anything as this is all you're going to do ultimately.
c) The software that doesn't port has to deal with the fact that it
> will be dropped by distributions. But any software with sufficiently
> many users to warrant packaging by the distributors should be able to
> find a maintainer that at least can keep it compiling.
Keeping something compiling is different from keeping something working;
not to mention that API breaks are non-trivial to port. Also this is not a
distributions' problem exclusively. Clients of Qt expect, and rightfully
so, binary compatibility which was promised. It wouldn't be surprising to
me to find an ebb of usage if we start breaking the ABI every 6 months just
because we decided we can. I don't even want to venture into the rabbit
hole that is 6-month lifetime of APIs.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Development