[Development] Deprecation/removal model going into Qt 6

[Jean-Michaël Celerier]

>  If existing package of application cannot be rebuilt from source with
updated
Qt version, it's a sure no-go for distibution. Either Qt update will be
blocked, or
application will be thrown away (or application will be somehow patched by
other
people, without you even knowing about that)

- People nowadays will just use the flatpak / appimage / snap / whatever
version which will be much more up-to date than Debian Stable's Qt 5.7 (!)
or Ubuntu LTS & CentOS 's Qt 5.9 anyways.
- boost has the exact same ABI stability issue (e.g. no ABI / API stability
guarantees at all) and yet distros seem to manage all the C++ software
which uses it without much problems.

My 0.02€
Jean-Michaël


On Sun, Jun 2, 2019 at 4:08 PM Konstantin Tokarev <annulen at yandex.ru> wrote:

>
>
> 02.06.2019, 17:03, "Manuel Bergler" <berglerma at gmail.com>:
> > 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.
>
> If existing package of application cannot be rebuilt from source with
> updated
> Qt version, it's a sure no-go for distibution. Either Qt update will be
> blocked, or
> application will be thrown away (or application will be somehow patched by
> other
> people, without you even knowing about that)
>
> --
> Regards,
> Konstantin
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190602/84c115f0/attachment.html>