Remove section on versioning for specific changes -- individual schem…

…a pages should cover this instead

CONTRIBUTING.md

@@ -58,25 +58,6 @@ Compatibility typically implies that a client using an updated version of the sc
 These suggestions need not be followed strictly, and there may be exceptions.
 For instance, some operations which are technically backward-compatible, such as adding a table, should likely trigger a `MAJOR` version increment rather than `MINOR`, as they would constitute an important and significant update, potentially requiring significant changes to client code or APIs.
 
-Versioning Guidelines
----------------------
-
-Below are some general guidelines that can be used for incrementing the schema version based on what changes are being made:
-
-| Operation | Increment | Notes |
-|--------|-----------|-------|
-| Add table | MAJOR | Even if backward compatible, new tables often signal major functionality changes, usually requiring clients to update their code or queries. |
-| Remove table | MAJOR | Removing a table may break existing queries and client interfaces, making it incompatible with previous versions. |
-| Add column | MAJOR | Adding a column may require clients to adapt to the new data structure (e.g., parsing new fields), treated as a major change for consistency. |
-| Remove column | MAJOR | Removing a column breaks queries and code expecting that column, thus not backward compatible. |
-| Change column type| MAJOR | Changing a column’s data type can break clients expecting a different type, forcing a major version increment. |
-| Add index | PATCH | Indexes improve performance without changing the schema’s interface, making this a safe, backward-compatible improvement. |
-| Add constraint | MAJOR | New constraints can invalidate previously acceptable data, breaking clients that rely on the old lenient rules. |
-| Change constraint | MAJOR | Altered constraints can break clients relying on the previous constraint behavior, making this a non-backward-compatible change. |
-| Remove constraint | MINOR | Removing a constraint generally relaxes restrictions. It’s unlikely to break clients, but it changes behavior enough to warrant more than a patch. |
-| Change metadata | PATCH | Adjusting metadata that does not affect the schema’s functional behavior or data shape is a minor adjustment that remains backward compatible. |
-
-The above are only suggestions.
 The [specific schema documentation](#specific-schema-documentation) should be consulted for more specific rules and guidelines on version incrementing.
 
 Database Migration