Qt-Version-Compatibility: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
(→‎Additional Information: Link to page I'm about to create ...)
(Link relevant QUIPs.)
 
(6 intermediate revisions by 3 users not shown)
Line 3: Line 3:
Qt uses a major.minor.patch numbering scheme for Qt releases. For example, Qt 5.0.1 represents the 1st patch release of Qt 5.0. Each release has restrictions on what kind of changes are acceptable, in order to provide a predictable and stable API. This enables users who are only interested in certain types of improvements to be sure that they won't be adversely affected by upgrading to a newer version.
Qt uses a major.minor.patch numbering scheme for Qt releases. For example, Qt 5.0.1 represents the 1st patch release of Qt 5.0. Each release has restrictions on what kind of changes are acceptable, in order to provide a predictable and stable API. This enables users who are only interested in certain types of improvements to be sure that they won't be adversely affected by upgrading to a newer version.


We do our best to maintain compatibility between versions. However, in order to improve Qt it is sometimes necessary to break compatibility.
We do our best to maintain compatibility between versions. However, in order to improve Qt it is sometimes necessary to break compatibility. For more on this, see:
;{{QUIP|5}}: Choosing a Branch
;{{QUIP|6}}: Acceptable Source-Incompatible Changes


'''Major''' releases may break backwards binary and source compatibility, although source compatibility may be maintained.
'''Major''' releases may break backwards binary and source compatibility, although source compatibility may be maintained.
Line 13: Line 15:
== Binary Compatibility Guidelines ==
== Binary Compatibility Guidelines ==


<blockquote>A library is '''binary compatible''', if a program linked dynamically to a former version of the library continues running with newer versions of the library without the need to recompile.
<blockquote>A library is '''binary compatible''', if a program linked '''dynamically''' to a former version of the library continues running with newer versions of the library without the need to recompile.
- [https://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++ techbase.kde.org]
- [https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B community.kde.org]
</blockquote>
</blockquote>
Please note, that at the moment Qt requires static builds for iOS. Due to this, there might be some corner cases where BC is limited on iOS, for example, if an application uses its own or other libraries containing in-lined code.


== Source Compatibility Guidelines ==
== Source Compatibility Guidelines ==


<blockquote>If a program needs to be recompiled to run with a new version of library but doesn't require any further modifications, the library is '''source compatible'''.
<blockquote>If a program needs to be recompiled to run with a new version of library but doesn't require any further modifications, the library is '''source compatible'''.
- [https://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++ techbase.kde.org]
- [https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B community.kde.org]
</blockquote>
</blockquote>


Line 32: Line 36:


When preparing for a new release, we perform an [[API change review]] to check for any changes incompatible with this policy.
When preparing for a new release, we perform an [[API change review]] to check for any changes incompatible with this policy.
For examples of things you cannot do in C++ while maintaining binary compatibility, see [https://community.kde.org/Policies/Binary_Compatibility_Examples Binary Compatibility Examples].


== References ==
== References ==


* [https://wiki.qt.io/Qt-contributors-summit-2011-Qt5ProductDefinition#Compatibility_promise_and_Qt_release_numbering QtCS 2011 defined Qt5 compatibility promises]
* [https://wiki.qt.io/Qt-contributors-summit-2011-Qt5ProductDefinition#Compatibility_promise_and_Qt_release_numbering QtCS 2011 defined Qt5 compatibility promises]

Latest revision as of 14:12, 26 August 2024


Qt uses a major.minor.patch numbering scheme for Qt releases. For example, Qt 5.0.1 represents the 1st patch release of Qt 5.0. Each release has restrictions on what kind of changes are acceptable, in order to provide a predictable and stable API. This enables users who are only interested in certain types of improvements to be sure that they won't be adversely affected by upgrading to a newer version.

We do our best to maintain compatibility between versions. However, in order to improve Qt it is sometimes necessary to break compatibility. For more on this, see:

QUIP 5
Choosing a Branch
QUIP 6
Acceptable Source-Incompatible Changes

Major releases may break backwards binary and source compatibility, although source compatibility may be maintained.

Minor releases are backwards binary and source compatible.

Patch releases are both backwards and forwards binary and source compatible.

Binary Compatibility Guidelines

A library is binary compatible, if a program linked dynamically to a former version of the library continues running with newer versions of the library without the need to recompile.

- community.kde.org

Please note, that at the moment Qt requires static builds for iOS. Due to this, there might be some corner cases where BC is limited on iOS, for example, if an application uses its own or other libraries containing in-lined code.

Source Compatibility Guidelines

If a program needs to be recompiled to run with a new version of library but doesn't require any further modifications, the library is source compatible.

- community.kde.org

Compatibility in Modules

The modules in Qt Essentials have the same forward and backward compatibility promises as Qt 4: new Qt 5 minor releases will not break binary compatibility, and patch level releases are forward and backward compatible. Qt Add-On modules specify their compatibility promise separately.

Additional Information

For more information on which branch you should submit a change to depending on its compatibility, see the branch guidelines.

When preparing for a new release, we perform an API change review to check for any changes incompatible with this policy.

For examples of things you cannot do in C++ while maintaining binary compatibility, see Binary Compatibility Examples.

References