TeamHepta/SDL
1
0
Fork 0
mirror of https://github.com/libsdl-org/SDL.git synced 2026-03-20 15:51:07 +01:00
Code Issues Packages Projects Releases Wiki Activity

Updated version documentation to match SDL 3.x practice

Browse Source
This commit is contained in:
Sam Lantinga
2025-04-07 10:22:42 -07:00
parent adad7dcae0
commit cccad933a0
1 changed files with 28 additions and 40 deletions
Download Patch File Download Diff File Expand all files Collapse all files

68
docs/README-versions.md
View File

@@ -1,60 +1,48 @@
# Versioning # Versioning
## Since 2.23.0 ## Since 3.2.0
SDL follows an "odd/even" versioning policy, similar to GLib, GTK, Flatpak SDL follows an "odd/even" versioning policy, similar to GLib, GTK, Flatpak
and older versions of the Linux kernel: and older versions of the Linux kernel:
* The major version (first part) increases when backwards compatibility * If the minor version (second part) and the patch version (third part) is
is broken, which will happen infrequently. divisible by 2 (for example 3.2.6, 3.4.0), this indicates a version of
SDL that is believed to be stable and suitable for production use.
* If the minor version (second part) is divisible by 2
(for example 2.24.x, 2.26.x), this indicates a version of SDL that
is believed to be stable and suitable for production use.
* In stable releases, the patchlevel or micro version (third part) * In stable releases, the patchlevel or micro version (third part)
indicates bugfix releases. Bugfix releases should not add or indicates bugfix releases. Bugfix releases may add small changes
remove ABI, so the ".0" release (for example 2.24.0) should be to the ABI, so newer patch versions are backwards-compatible but
forwards-compatible with all the bugfix releases from the not fully forwards-compatible. For example, programs built against
same cycle (for example 2.24.1). SDL 3.2.0 should work fine with SDL 3.2.8, but programs built against
SDL 3.2.8 may not work with 3.2.0.
* The minor version increases when new API or ABI is added, or when * The minor version increases when significant changes are made that
other significant changes are made. Newer minor versions are require longer development or testing time, e.g. major new functionality,
backwards-compatible, but not fully forwards-compatible. or revamping support for a platform. Newer minor versions are
For example, programs built against SDL 2.24.x should work fine backwards-compatible, but not fully forwards-compatible. For example,
with SDL 2.26.x, but programs built against SDL 2.26.x will not programs built against SDL 3.2.x should work fine with SDL 3.4.x,
necessarily work with 2.24.x. but programs built against SDL 3.4.x may not work with 3.2.x.
* If the minor version (second part) is not divisible by 2 * If the minor version (second part) or patch version (third part) is not
(for example 2.23.x, 2.25.x), this indicates a development prerelease divisible by 2 (for example 3.2.9, 3.3.x), this indicates a development
of SDL that is not suitable for stable software distributions. prerelease of SDL that is not suitable for stable software distributions.
Use with caution. Use with caution.
* The patchlevel or micro version (third part) increases with * The patchlevel or micro version (third part) increases with each prerelease.
each prerelease.
* Each prerelease might add new API and/or ABI.
* Prereleases are backwards-compatible with older stable branches. * Prereleases are backwards-compatible with older stable branches.
For example, 2.25.x will be backwards-compatible with 2.24.x. For example, programs built against SDL 3.2.x should work fine with
SDL 3.3.x, but programs built against SDL 3.3.x may not work with 3.2.x.
* Prereleases are not guaranteed to be backwards-compatible with * Prereleases are not guaranteed to be backwards-compatible with each other.
each other. For example, new API or ABI added in 2.25.1 For example, new API or ABI added in 3.3.0 might be removed or changed in
might be removed or changed in 2.25.2. 3.3.1. If this would be a problem for you, please do not use prereleases.
If this would be a problem for you, please do not use prereleases.
* Only upgrade to a prerelease if you can guarantee that you will * Only use a prerelease if you can guarantee that you will promptly upgrade
promptly upgrade to the stable release that follows it. to the stable release that follows it. For example, do not use 3.3.x
For example, do not upgrade to 2.23.x unless you will be able to unless you will be able to upgrade to 3.4.0 when it becomes available.
upgrade to 2.24.0 when it becomes available.
* Software distributions that have a freeze policy (in particular Linux * Software distributions that have a freeze policy (in particular Linux
distributions with a release cycle, such as Debian and Fedora) distributions with a release cycle, such as Debian and Fedora)
should usually only package stable releases, and not prereleases. should only package stable releases, and not prereleases.
## Before 2.23.0
Older versions of SDL followed a similar policy, but instead of the
odd/even rule applying to the minor version, it applied to the patchlevel
(micro version, third part). For example, 2.0.22 was a stable release
and 2.0.21 was a prerelease.