From 1a94c4a3cb9b920642ca9f9549ccc6772d5636aa Mon Sep 17 00:00:00 2001 From: Daniel Stone Date: Thu, 29 Dec 2022 15:56:46 +0000 Subject: [PATCH] README: Delete misleading API-versioning section All of this sounded nice, but none of this was true. Signed-off-by: Daniel Stone --- README.md | 40 ---------------------------------------- 1 file changed, 40 deletions(-) diff --git a/README.md b/README.md index 30d8306d..16072c78 100644 --- a/README.md +++ b/README.md @@ -218,46 +218,6 @@ Depending only on libweston-3 without a specific version number still allows pre-releases which might have different API or ABI. -Forward compatibility ---------------------- - -Inspired by ATK, Qt and KDE programs/libraries, libjpeg-turbo, GDK, -NetworkManager, js17, lz4 and many others, libweston uses a macro to restrict -the API visible to the developer - REQUIRE_LIBWESTON_API_VERSION. - -Note that different projects focus on different aspects - upper and/or lower -version check, default to visible/hidden old/new symbols and so on. - -libweston aims to guard all newly introduced API, in order to prevent subtle -breaks that a simple recompile (against a newer version) might cause. - -The macro is of the format 0x$MAJOR$MINOR and does not include PATCH version. -As mentioned in the Versioning scheme section, the latter does not reflect any -user visible API changes, thus should be not considered part of the API version. - -All new symbols should be guarded by the macro like the example given below: - -~~~~ -#if REQUIRE_LIBWESTON_API_VERSION >= 0x0101 - -bool -weston_ham_sandwich(void); - -#endif -~~~~ - -In order to use the said symbol, the one will have a similar code in their -configure.ac: - -~~~~ -PKG_CHECK_MODULES(LIBWESTON, [libweston-1 >= 1.1]) -AC_DEFINE(REQUIRE_LIBWESTON_API_VERSION, [0x0101]) -~~~~ - -If the user is _not_ interested in forward compatibility, they can use 0xffff -or similar high value. Yet doing so is not recommended. - - Libweston design goals ----------------------