Attempt to reword section on backward compatibility

docs/APDB.md

@@ -11,8 +11,8 @@ The versioning system of the APDB is outlined in [DMTN-269](https://dmtn-269.lss
 The deployed database schema is a product of the [schema in sdm_schemas](../python/lsst/sdm_schemas/schemas/apdb.yaml) and processing by tools in the [dax_apdb](https://github.com/lsst/dax_apdb) repository.
 Compatibility of the client executable with the actual database schema is determined by the version number in `apdb.yaml` and that which is stored in the database metadata.
 
-Backward compatibility in the context of the APDB implies that a client using an interface derived from a schema with a higher `MINOR` version number will be able to read and write into a database with a lower `MINOR` version -- in other words, an existing APDB need not be migrated to match newer clients.
-But a client using a lower `MINOR` version number will not be compatible with a database that contains the changes from a higher version.
+Backward compatibility in the context of the APDB implies that a client using a schema with a higher minor version will be able to read and write into a database with a lower minor version -- in other words, an existing database instance need not be migrated to match the newer client interface.
+But a client using a schema with a lower minor version will be incompatible with a database that has a higher version number.
 There may be cases where significant schema changes may still be compatible if the client can handle them transparently.
 
 Typical Schema Changes