Hi,
I'm now working on Qt 5.15.5 update in Rawhide. As you probably know, Qt 5.15 is the last major release of Qt 5 and all the development is now focused to Qt 6. This means that all the upcoming releases of Qt 5 are meant to be bugfix releases and therefore no API/ABI changes are expected. For that reason we have decided to no longer depend on the exact version of Qt that apps were built against. We did this with all the applications using Qt's private API and this resulted in ~80 packages that needed to be rebuilt everytime we did just a Qt bugfix update, making the whole update process complicated and long. This change should result in faster and more simple updates allowing us to bring newer Qt sooner as no one was really rushing to do Qt updates before for all the complexity.
There are just a few packages where I'm going to keep this requirement as we want to be sure to not break anything. These are: *qt5-qtwebengine, deepin-qt5integration, deepin-qt5platform-plugins, qgnomeplatform, fcitx-qt5, kf5-frameworkintegration, plasma-integration, qt5ct and python-qt5.*
If you believe your package should depend on the exact Qt version it was built against then let me know so I can change it back and put it on my list for future rebuilds. Let me know even in case you think your package doesn't need to be rebuilt and I listed it above.
Bug for reference: https://pagure.io/fedora-kde/SIG/issue/215
Thank you.
Regards,
On 14/07/2022 14:59, Jan Grulich wrote:
This means that all the upcoming releases of Qt 5 are meant to be bugfix releases and therefore no API/ABI changes are expected. For that reason we have decided to no longer depend on the exact version of Qt that apps were built against.
Are you sure? Telegram Desktop previously had major GUI breakages between patch version of Qt 5. I asked Qt upstream and they replied that Qt doesn't have ABI compatibility even between patch releases.
čt 14. 7. 2022 v 19:29 odesílatel Vitaly Zaitsev via devel < devel@lists.fedoraproject.org> napsal:
On 14/07/2022 14:59, Jan Grulich wrote:
This means that all the upcoming releases of Qt 5 are meant to be bugfix releases and therefore no API/ABI changes are expected. For that reason we have decided to no longer depend on the exact version of Qt that apps were built against.
Are you sure? Telegram Desktop previously had major GUI breakages between patch version of Qt 5. I asked Qt upstream and they replied that Qt doesn't have ABI compatibility even between patch releases.
Telegram is not a great example, or rather it's a great example of an app that should always depend on the exact Qt version it was built against. They are using private API more than any other application with tons of custom implementations.
I'm 100% sure Qt doesn't break ABI compatibility between patch releases for public API. Would you be a happy paying customer if they break ABI for a library you are paying for? With private API there is no such promise, but I don't think ABI breakages will happen at this point.
Regards, Jan
On 15/07/2022 07:48, Jan Grulich wrote:
I'm 100% sure Qt doesn't break ABI compatibility between patch releases for public API. Would you be a happy paying customer if they break ABI for a library you are paying for? With private API there is no such promise, but I don't think ABI breakages will happen at this point.
For example you can build Telegram Desktop against 5.15.0 and then try to run it under 5.15.4. The GUI will be completely broken and unusable. Also messages will be displayed vertically - each letter on a new line.
Same for Qt 6.
Telegram is not a great example, or rather it's a great example of an app that should always depend on the exact Qt version it was built against. They are using private API more than any other application with tons of custom implementations.
Now they only use the private APIs of QtGui and QtWayland.
On 7/14/22 20:59, Jan Grulich wrote:
Hi,
I'm now working on Qt 5.15.5 update in Rawhide. As you probably know, Qt 5.15 is the last major release of Qt 5 and all the development is now focused to Qt 6. This means that all the upcoming releases of Qt 5 are meant to be bugfix releases and therefore no API/ABI changes are expected. For that reason we have decided to no longer depend on the exact version of Qt that apps were built against. We did this with all the applications using Qt's private API and this resulted in ~80 packages that needed to be rebuilt everytime we did just a Qt bugfix update, making the whole update process complicated and long. This change should result in faster and more simple updates allowing us to bring newer Qt sooner as no one was really rushing to do Qt updates before for all the complexity.
There are just a few packages where I'm going to keep this requirement as we want to be sure to not break anything. These are: *qt5-qtwebengine, deepin-qt5integration, deepin-qt5platform-plugins, qgnomeplatform, fcitx-qt5, kf5-frameworkintegration, plasma-integration, qt5ct and python-qt5.*
If you believe your package should depend on the exact Qt version it was built against then let me know so I can change it back and put it on my list for future rebuilds. Let me know even in case you think your package doesn't need to be rebuilt and I listed it above.
Hi Jan,
It's unfortunate that this goes in parallel with my doing LXQt update in a side tag. I'm now in the situation of having some of the packages built but 3 remaining are not due to FTI of my already built packages. So I'm writing to see if you've already finished the update? If so, I'll just bump and rebuild my dependency. If not, shall I just wait for you or do you have any suggestions?
Thanks.
Bug for reference: https://pagure.io/fedora-kde/SIG/issue/215 https://pagure.io/fedora-kde/SIG/issue/215
Thank you.
Regards,
Jan Grulich,
Senior Software Engineer, Desktop Team
Red Hat
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 7/16/22 18:50, Zamir SUN wrote:
On 7/14/22 20:59, Jan Grulich wrote:
Hi,
I'm now working on Qt 5.15.5 update in Rawhide. As you probably know, Qt 5.15 is the last major release of Qt 5 and all the development is now focused to Qt 6. This means that all the upcoming releases of Qt 5 are meant to be bugfix releases and therefore no API/ABI changes are expected. For that reason we have decided to no longer depend on the exact version of Qt that apps were built against. We did this with all the applications using Qt's private API and this resulted in ~80 packages that needed to be rebuilt everytime we did just a Qt bugfix update, making the whole update process complicated and long. This change should result in faster and more simple updates allowing us to bring newer Qt sooner as no one was really rushing to do Qt updates before for all the complexity.
There are just a few packages where I'm going to keep this requirement as we want to be sure to not break anything. These are: *qt5-qtwebengine, deepin-qt5integration, deepin-qt5platform-plugins, qgnomeplatform, fcitx-qt5, kf5-frameworkintegration, plasma-integration, qt5ct and python-qt5.*
If you believe your package should depend on the exact Qt version it was built against then let me know so I can change it back and put it on my list for future rebuilds. Let me know even in case you think your package doesn't need to be rebuilt and I listed it above.
Hi Jan,
It's unfortunate that this goes in parallel with my doing LXQt update in a side tag. I'm now in the situation of having some of the packages built but 3 remaining are not due to FTI of my already built packages. So I'm writing to see if you've already finished the update? If so, I'll just bump and rebuild my dependency. If not, shall I just wait for you or do you have any suggestions?
Ignore my previous email. I've rebuilt my package and solved the issue.
Sorry for the noise.
Thanks.
Bug for reference: https://pagure.io/fedora-kde/SIG/issue/215 https://pagure.io/fedora-kde/SIG/issue/215
Thank you.
Regards,
Jan Grulich,
Senior Software Engineer, Desktop Team
Red Hat
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
-
Jan Grulich -
Vitaly Zaitsev -
Zamir SUN