diff --git a/documentation/content/en/books/developers-handbook/policies/chapter.adoc b/documentation/content/en/books/developers-handbook/policies/chapter.adoc
--- a/documentation/content/en/books/developers-handbook/policies/chapter.adoc
+++ b/documentation/content/en/books/developers-handbook/policies/chapter.adoc
@@ -323,21 +323,13 @@
 
 If you are adding shared library support to a port or other piece of software that does not have one, the version numbers should follow these rules. Generally, the resulting numbers will have nothing to do with the release version of the software.
 
-The three principles of shared library building are:
-
-* Start from `1.0`
-* If there is a change that is backwards compatible, bump minor number (note that ELF systems ignore the minor number)
-* If there is an incompatible change, bump major number
-
-For instance, added functions and bugfixes result in the minor version number being bumped, while deleted functions, changed function call syntax, etc. will force the major version number to change.
-
-Stick to version numbers of the form major.minor (`_x_._y_`). Our a.out dynamic linker does not handle version numbers of the form `_x_._y_._z_` well. Any version number after the `_y_` (i.e., the third digit) is totally ignored when comparing shared lib version numbers to decide which library to link with. Given two shared libraries that differ only in the "micro" revision, `ld.so` will link with the higher one. That is, if you link with [.filename]#libfoo.so.3.3.3#, the linker only records `3.3` in the headers, and will link with anything starting with `_libfoo.so.3_._(anything >= 3)_._(highest available)_`.
-
-[NOTE]
-====
-`ld.so` will always use the highest "minor" revision. For instance, it will use [.filename]#libc.so.2.2# in preference to [.filename]#libc.so.2.0#, even if the program was initially linked with [.filename]#libc.so.2.0#.
-====
-
-In addition, our ELF dynamic linker does not handle minor version numbers at all. However, one should still specify a major and minor version number as our [.filename]#Makefile#'s "do the right thing" based on the type of system.
+The principles of shared library major numbers are:
+
+* Start from `1`
+* If there is a change that is backwards compatible, no adjustment is necessary
+* If there is an incompatible change, there are a few options:
+** If the library uses versioned symbols, bump the version of affected symbols and provide compatibility versions of affected symbols under the old version
+** If the library uses versioned symbols, but the compatibility cannot be preserved with compatibility symbols (e.g. the layout of an exported global variable changed), bump the major number.  Along with bumping the major number, old compatibility symbols should be removed
+** If the library does not use versioned symbols, bump major number.  Consider adding a version map to begin versioning symbols when bumping the major
 
 For non-port libraries, it is also our policy to change the shared library version number only once between releases. In addition, it is our policy to change the major shared library version number only once between major OS releases (i.e., from 6.0 to 7.0). When you make a change to a system library that requires the version number to be bumped, check the [.filename]#Makefile#'s commit logs. It is the responsibility of the committer to ensure that the first such change since the release will result in the shared library version number in the [.filename]#Makefile# to be updated, and any subsequent changes will not.