[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