1 files changed, 40 insertions, 0 deletions
diff --git a/build/bootstrap.build b/build/bootstrap.build
new file mode 100644
index 0000000..d8cff23
--- /dev/null
+++ b/build/bootstrap.build
@@ -0,0 +1,40 @@
+# file      : build/bootstrap.build
+# copyright : Copyright (c) 2016-2017 Code Synthesis Ltd
+# license   : GPLv2 with FOSS License Exception; see accompanying COPYING file
+
+project = libmysqlclient
+
+using version
+using config
+using dist
+using test
+using install
+
+# The MySQL client library ABI version number has the <major>.<minor>.<patch>
+# form. The major number is increased for backwards-incompatible API changes,
+# the minor number for backwards-compatible ones (for example, for adding a new
+# function), and the patch number is typically increased for each package
+# release, being in a sense redundant. Increase of the version component resets
+# the rightmost ones to zero. See also:
+#
+# http://mysqlserverteam.com/the-client-library-part-2-the-version-number/
+#
+# There is no way to deduce the ABI version from the release version, so we
+# obtain the ABI version from the SHARED_LIB_MAJOR_VERSION variable value in
+# cmake/mysql_version.cmake for each package release. Also, while at it, check
+# that the protocol version is still correct (the PROTOCOL_VERSION variable).
+#
+# See also how Debian/Fedora package libmariadb if trying to wrap your head
+# around this mess.
+#
+if ($version.major == 5 && $version.minor == 7 && $version.patch == 20)
+{
+  # @@ Should we also use the ABI minor version to make sure the library is
+  #    also forward-compatible?
+  #
+  abi_version = 20
+
+  protocol_version = 10
+}
+else
+  fail "increment the ABI version?"