Two-way BC in Patch Releases: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
(Created page with "Category:QtCS2023 ==Session Summary== ==Session Owners== ==Notes==")
 
No edit summary
 
Line 3: Line 3:
==Session Summary==
==Session Summary==


* Problem: do we want to allow downgrading, e.g. building against newer Qt, running against older Qt
* Conclusion: not useful, and not verified by any test machinery
* Next step: send proposal to mailing list to drop the commitment
* No steps taken by us to detect a "downgrade" situation


==Session Owners==
==Session Owners==


Volker Hilsheimer


==Notes==
==Notes==
Background email thread: https://lists.qt-project.org/pipermail/development/2023-August/044333.html
* Anything we cannot do in minor releases we cannot do in patch releases
* Is this ever useful? Downgrading might not work for many reasons
** if you do it, you are on your own (it might work)
* If we want to support it, then we should also test it
** run tests against an installation of older binaries
* Forward BC has many nuances
** adding overrides
** modifying inline functions
** bug-compatibility
** -> generally, applications might have to be recompiled
* Linux distributions perspective
** When a new application is downloaded that has been built against a newer .so-name that what is part of the Linux distro
** Will installing an app with a more recent Qt dependency that pull down a new Qt version?
** according to Allan, that would be the case on Debian
** newer Qt version wouldn't be a problem (from a BC perspective at least)
** our .so names don't include the patch level
* existing exceptions for enums (QLocale), OS versions
** our implementation handles that, e.g. in QLocale comparing enum value received against known last value
* Our BiC test is run as part of qt5.git testing - late
** de-facto, we might have already abandoned the commitment to provide forward-compatibility within a patch cycle
** test does not compare symbols exported by a library; could, but requires investment in the test
* LTS situation
** current minor version might have fewer fixes than latest LTS patch release (e.g. 6.2.7 might be newer than 6.3.x)
** most customers go from LTS to LTS
** but if 6.2.7 adds a new symbol, then it might not be in the currently available 6.5.x either
** installing on a system with older Qt is anyway problematic, people ship their own Qt binaries (snap/bundle etc)

Latest revision as of 14:02, 1 December 2023


Session Summary

  • Problem: do we want to allow downgrading, e.g. building against newer Qt, running against older Qt
  • Conclusion: not useful, and not verified by any test machinery
  • Next step: send proposal to mailing list to drop the commitment
  • No steps taken by us to detect a "downgrade" situation

Session Owners

Volker Hilsheimer

Notes

Background email thread: https://lists.qt-project.org/pipermail/development/2023-August/044333.html

  • Anything we cannot do in minor releases we cannot do in patch releases
  • Is this ever useful? Downgrading might not work for many reasons
    • if you do it, you are on your own (it might work)
  • If we want to support it, then we should also test it
    • run tests against an installation of older binaries
  • Forward BC has many nuances
    • adding overrides
    • modifying inline functions
    • bug-compatibility
    • -> generally, applications might have to be recompiled
  • Linux distributions perspective
    • When a new application is downloaded that has been built against a newer .so-name that what is part of the Linux distro
    • Will installing an app with a more recent Qt dependency that pull down a new Qt version?
    • according to Allan, that would be the case on Debian
    • newer Qt version wouldn't be a problem (from a BC perspective at least)
    • our .so names don't include the patch level
  • existing exceptions for enums (QLocale), OS versions
    • our implementation handles that, e.g. in QLocale comparing enum value received against known last value
  • Our BiC test is run as part of qt5.git testing - late
    • de-facto, we might have already abandoned the commitment to provide forward-compatibility within a patch cycle
    • test does not compare symbols exported by a library; could, but requires investment in the test
  • LTS situation
    • current minor version might have fewer fixes than latest LTS patch release (e.g. 6.2.7 might be newer than 6.3.x)
    • most customers go from LTS to LTS
    • but if 6.2.7 adds a new symbol, then it might not be in the currently available 6.5.x either
    • installing on a system with older Qt is anyway problematic, people ship their own Qt binaries (snap/bundle etc)
Retrieved from "https://wiki.qt.io/index.php?title=Two-way_BC_in_Patch_Releases&oldid=41092"