[Development] Deprecation/removal model going into Qt 6

[Manuel Bergler]

Am So., 2. Juni 2019 um 15:50 Uhr schrieb Konstantin Tokarev
<annulen at yandex.ru>:
>
>
>
> 02.06.2019, 16:34, "Manuel Bergler" <berglerma at gmail.com>:
> > Due to Hyrum's law [0], even with stricter guarantees there will
> > always be someone for which migration is a non-trivial amount of work.
> > The only way to avoid that is to change nothing, ever. I personally
> > also don't understand why people would expect getting shiny new
> > features of a new minor release without having to pay a cost of
> > migrating their code over. I believe that as long as the benefit of
> > the new features outweighs the cost of migration then people will be
> > willing to migrate anyway. I myself don't mind the 2 weeks it took so
> > far to upgrade from Qt 5.9 to Qt 5.12 in our project, that's just the
> > cost of progress...
>
> In open source world Qt version is not easily chosen by developer.
> If Qt updates are source-incompatible, distributions will stuck with old Qt
> as long as possible to avoid massive breakages, and if new version of your
> app requeres newer Qt than what is shipped by distribution, users will get
> older version which is still compatible.

That's why I suggested using inline namespaces. Then even if an
application no longer compiles with the new version of Qt it can still
link against it. Thus, distributions can freely update Qt without
breaking any client packages, they just need to ship what they shipped
before and it'll just work*. Or are you saying that distributions
would still not update Qt because they might break code that their
users wrote that isn't part of the distributions package repository?
In that case distributions can still choose to ship different versions
of Qt side-by-side as I suggested earlier, most distributions already
do that for Qt4 and Qt5.

Best
Manuel

* at least just as good as it "works" right now, i.e. ignoring silent
behavior changes