[Development] Deprecation/removal model going into Qt 6

Konstantin Tokarev annulen at yandex.ru
Sun Jun 2 16:07:09 CEST 2019

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)


More information about the Development mailing list