Document field-id requirements for partition specs and fix doc formatting

Author: jun-he

site/docs/spec.md

@@ -646,6 +646,18 @@ Each partition field in the fields list is stored as an object. See the table fo
 
 In some cases partition specs are stored using only the field list instead of the object format that includes the spec ID, like the deprecated `partition-spec` field in table metadata. The object format should be used unless otherwise noted in this spec.
 
+#### Partition Field ID handling
+
+A partition field id is an integer (starting at 1000) used to identify a partition field.
+
+Since iceberg release 0.8.0, partition fields are present in every partition field of partition specs in a table metadata.
+
+* For backward compatibility, if field ids are missing in a table metadata, iceberg will sequentially generate ids for each field starting at 1000 based on its position in the list of fields.
+* For forward compatibility, if field ids are not supported, iceberg will ignore field ids.
+
+Additionally, in table metadata format v2, partition fields are required to have unique field IDs to support partition spec evolution.
+
+For tables without partition field IDs, iceberg will generate an auto-increment unique field id starting at 1000 for every partition field.
 
 ### Table Metadata and Snapshots
 
@@ -698,14 +710,17 @@ This serialization scheme is for storing single values as individual binary valu
 ### Version 2
 
 Writing v1 metadata:
+
 * Table metadata field `last-sequence-number` should not be written.
 * Snapshot field `sequence-number` should not be written.
 
 Reading v1 metadata:
+
 * Table metadata field `last-sequence-number` must default to 0.
 * Snapshot field `sequence-number` must default to 0.
 
 Writing v2 metadata:
+
 * Table metadata added required field `last-sequence-number`.
 * Table metadata now requires field `table-uuid`.
 * Table metadata now requires field `partition-specs`.