[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)

-- 
Regards,
Konstantin




More information about the Development mailing list