> 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 <annu...@yandex.ru> wrote: > > > 02.06.2019, 17:03, "Manuel Bergler" <bergle...@gmail.com>: > > Am So., 2. Juni 2019 um 15:50 Uhr schrieb Konstantin Tokarev > > <annu...@yandex.ru>: > >> 02.06.2019, 16:34, "Manuel Bergler" <bergle...@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@qt-project.org > https://lists.qt-project.org/listinfo/development >
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development