summaryrefslogtreecommitdiff
path: root/XorgModuleABIVersions.mdwn
diff options
context:
space:
mode:
Diffstat (limited to 'XorgModuleABIVersions.mdwn')
-rw-r--r--XorgModuleABIVersions.mdwn25
1 files changed, 12 insertions, 13 deletions
diff --git a/XorgModuleABIVersions.mdwn b/XorgModuleABIVersions.mdwn
index f02c4268..3a158835 100644
--- a/XorgModuleABIVersions.mdwn
+++ b/XorgModuleABIVersions.mdwn
@@ -1,23 +1,22 @@
+The Xorg server includes version numbers for various ABI's for interfaces used by loadable modules such as drivers and extensions.
-The Xorg server includes version numbers for various ABI's for interfaces used by loadable modules such as drivers and extensions.
+This major number of the ABI version (_**x**_.\*) is incremented when there are incompatible changes in module API/ABI's, while the minor number (\*._**x**_) is incremented for compatible additions.
-This major number of the ABI version (_**x**_.*) is incremented when there are incompatible changes in module API/ABI's, while the minor number (*._**x**_) is incremented for compatible additions.
+Modules reporting they require a incompatible version number will not be loaded unless the `-ignoreABI` option is used. (Modules can also check ABI versions themselves, and choose which function variant to call or structure variant to access, based on the reported versions - this is the option used by some closed source drivers for instance.)
-Modules reporting they require a incompatible version number will not be loaded unless the `-ignoreABI` option is used. (Modules can also check ABI versions themselves, and choose which function variant to call or structure variant to access, based on the reported versions - this is the option used by some closed source drivers for instance.)
-
-ABI numbers may increment multiple times during Xorg server development cycles, to track changes for those following the head of the development stream. X.Org tries to avoid changing ABI's incompatibly in stable release branches.
+ABI numbers may increment multiple times during Xorg server development cycles, to track changes for those following the head of the development stream. X.Org tries to avoid changing ABI's incompatibly in stable release branches.
[[!table header="no" class="mointable" data="""
- **Xorg Version: ** | **[[1.3|Server13Branch]] ** | **[[1.4|Server14Branch]]** | **[[1.5|Server15Branch]]** | **[[1.6|Server16Branch]]** | **[[1.7|Server17Branch]]** | **1.8** | **1.9** | **1.10** | **1.11**
- ABI_ANSIC_VERSION | 0.3 | 0.3 | 0.4 | 0.4 | 0.4 | 0.4 | 0.4 | 0.4 | 0.4
- ABI_VIDEODRV_VERSION | 1.2 | 2.0 | 4.1 | 5.0 | 6.0 | 7.0 | 8.0 | 10.0 | 11.0
- ABI_XINPUT_VERSION | 0.7 | 2.0 | 2.1 | 4.0 | 7.0 | 9.0 | 11.0 | 12.2 | 13.0
- ABI_EXTENSION_VERSION | 0.3 | 0.3 | 1.1 | 2.0 | 2.0 | 3.0 | 4.0 | 5.0 | 5.0
- ABI_FONT_VERSION | 0.5 | 0.5 | 0.6 | 0.6 | 0.6 | 0.6 | 0.6 | 0.6 | 0.6
+ **Xorg Version:** | **[[1.3|Server13Branch]]** | **[[1.4|Server14Branch]]** | **[[1.5|Server15Branch]]** | **[[1.6|Server16Branch]]** | **[[1.7|Server17Branch]]** | **1.8** | **1.9** | **1.10** | **1.11**
+ ABI_ANSIC_VERSION | 0.3 | 0.3 | 0.4 | 0.4 | 0.4 | 0.4 | 0.4 | 0.4 | 0.4
+ ABI_VIDEODRV_VERSION | 1.2 | 2.0 | 4.1 | 5.0 | 6.0 | 7.0 | 8.0 | 10.0 | 11.0
+ ABI_XINPUT_VERSION | 0.7 | 2.0 | 2.1 | 4.0 | 7.0 | 9.0 | 11.0 | 12.2 | 13.0
+ ABI_EXTENSION_VERSION | 0.3 | 0.3 | 1.1 | 2.0 | 2.0 | 3.0 | 4.0 | 5.0 | 5.0
+ ABI_FONT_VERSION | 0.5 | 0.5 | 0.6 | 0.6 | 0.6 | 0.6 | 0.6 | 0.6 | 0.6
"""]]
## Input ABI policy
-Note: this is a guideline more so than a strict rule.
+Note: this is a guideline more so than a strict rule.
-The input ABI is bumped whenever an incompatible change is introduced to the server. This may happen several times during a development cycle. The goal of the ABI management is to allow the master branch of the various input drivers to compile when bisecting the server. If multiple changes to the server's ABI are required, these changes are usually accumulated and pushed in one merge.
+The input ABI is bumped whenever an incompatible change is introduced to the server. This may happen several times during a development cycle. The goal of the ABI management is to allow the master branch of the various input drivers to compile when bisecting the server. If multiple changes to the server's ABI are required, these changes are usually accumulated and pushed in one merge.