SDL_ttf: Updated version documentation to match SDL 3.x practice

From be0b8e323985208f7f4ac9708f2c53ebfdc09c9c Mon Sep 17 00:00:00 2001
From: Sam Lantinga <[EMAIL REDACTED]>
Date: Mon, 7 Apr 2025 10:27:28 -0700
Subject: [PATCH] Updated version documentation to match SDL 3.x practice

---
 docs/README-versions.md | 73 +++++++++++++++++------------------------
 1 file changed, 31 insertions(+), 42 deletions(-)

diff --git a/docs/README-versions.md b/docs/README-versions.md
index cbb59b84..6c2d920c 100644
--- a/docs/README-versions.md
+++ b/docs/README-versions.md
@@ -1,59 +1,48 @@
 # Versioning
 
-## Since 2.19.0
+## Since 3.2.0
 
-`SDL_ttf` 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:
 
-* The major version (first part) increases when backwards compatibility
-    is broken, which will happen infrequently.
-
-* If the minor version (second part) is divisible by 2
-    (for example 2.20.x, 2.22.x), this indicates a version that
-    is believed to be stable and suitable for production use.
+* If the minor version (second part) and the patch version (third part) is
+    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.
 
     * In stable releases, the patchlevel or micro version (third part)
-        indicates bugfix releases. Bugfix releases should not add or
-        remove ABI, so the ".0" release (for example 2.20.0) should be
-        forwards-compatible with all the bugfix releases from the
-        same cycle (for example 2.20.1).
-
-    * The minor version increases when new API or ABI is added, or when
-        other significant changes are made. Newer minor versions are
-        backwards-compatible, but not fully forwards-compatible.
-        For example, programs built against `SDL_ttf` 2.20.x should work fine
-        with 2.20.x, but programs built against 2.22.x will not necessarily
-        work with 2.20.x.
-
-* If the minor version (second part) is not divisible by 2
-    (for example 2.19.x, 2.21.x), this indicates a development prerelease
-    that is not suitable for stable software distributions.
+        indicates bugfix releases. Bugfix releases may add small changes
+        to the ABI, so newer patch versions are backwards-compatible but
+        not fully forwards-compatible. For example, programs built against
+        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 significant changes are made that
+        require longer development or testing time, e.g. major new functionality,
+        or revamping support for a platform. Newer minor versions are
+        backwards-compatible, but not fully forwards-compatible. For example,
+        programs built against SDL 3.2.x should work fine with SDL 3.4.x,
+        but programs built against SDL 3.4.x may not work with 3.2.x.
+
+* If the minor version (second part) or patch version (third part) is not
+    divisible by 2 (for example 3.2.9, 3.3.x), this indicates a development
+    prerelease of SDL that is not suitable for stable software distributions.
     Use with caution.
 
-    * The patchlevel or micro version (third part) increases with
-        each prerelease.
-
-    * Each prerelease might add new API and/or ABI.
+    * The patchlevel or micro version (third part) increases with each prerelease.
 
     * Prereleases are backwards-compatible with older stable branches.
-        For example, 2.21.x will be backwards-compatible with 2.20.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
-        each other. For example, new API or ABI added in 2.19.1
-        might be removed or changed in 2.19.2.
-        If this would be a problem for you, please do not use prereleases.
+    * Prereleases are not guaranteed to be backwards-compatible with each other.
+        For example, new API or ABI added in 3.3.0 might be removed or changed in
+        3.3.1. 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
-        promptly upgrade to the stable release that follows it.
-        For example, do not upgrade to 2.19.x unless you will be able to
-        upgrade to 2.20.0 when it becomes available.
+    * Only use a prerelease if you can guarantee that you will promptly upgrade
+        to the stable release that follows it. For example, do not use 3.3.x
+        unless you will be able to upgrade to 3.4.0 when it becomes available.
 
     * Software distributions that have a freeze policy (in particular Linux
         distributions with a release cycle, such as Debian and Fedora)
-        should usually only package stable releases, and not prereleases.
-
-## Before 2.19.0
+        should only package stable releases, and not prereleases.
 
-Older versions of `SDL_ttf` used the patchlevel (micro version,
-third part) for feature releases, and did not distinguish between feature
-and bugfix releases.