etseidl commented on code in PR #186:
URL: https://github.com/apache/parquet-site/pull/186#discussion_r3364651362


##########
content/en/docs/File Format/versions.md:
##########
@@ -0,0 +1,265 @@
+---
+title: "Parquet format versions"
+linkTitle: "Format versions"
+weight: 9
+---
+
+This page describes how features are added to the [Parquet format
+specification](https://github.com/apache/parquet-format) and how they affect
+reader and writer compatibility. See the
+[Implementation status](../implementationstatus/) page for which 
implementations
+(arrow, parquet-java, arrow-rs, etc.) support each feature.
+
+*Note*: If you find out-of-date information, please open an issue or pull 
request.
+
+## Feature compatibility
+
+The Parquet format spec [classifies changes] by their effect on reader and
+writer compatibility. Changes differ in their *forward* compatibility — whether
+an older reader can read files that use a newer feature.
+
+**Forward compatible** features remain **readable by older readers**, with a
+possibly degraded experience: some metadata may be missing or performance may
+suffer, but the reader does not fail. Examples:
+
+* **Bloom filters**: a reader that ignores them skips the pruning metadata but
+  still reads the data correctly.
+* **Logical type annotations** such as `VARIANT`: an older reader reads the
+  underlying physical column (e.g. `BYTE_ARRAY`) as raw bytes without applying
+  the logical type.
+
+**Forward incompatible** features make the data **unreadable** to older 
software.
+Examples:
+
+Backwards incompatible features make the data **unreadable** to older software
+that does not support them. Examples:
+
+* **New encodings** (e.g. the `DELTA_*` encodings, `BYTE_STREAM_SPLIT`,
+  `RLE_DICTIONARY`): a reader that does not implement them cannot decode the
+  column values.
+* **Data Page V2 headers**: a reader that only understands `DataPageHeader`
+  cannot parse `DataPageHeaderV2` pages.
+
+[classifies changes]: 
https://github.com/apache/parquet-format/blob/master/CONTRIBUTING.md#compatibility-and-feature-enablement
+
+## `FileMetadata` version field
+
+Each Parquet file has a `version` field in the [`thrift FileMetadata`] that

Review Comment:
   That's one option, but I think we'll always want 'PAR', so that limits how 
many changes we can make with the remaining byte ('1' and 'E' are taken, so I 
guess that leaves 254 more, fewer if we restrict ourselves to ASCII 🤣). I 
proposed in the M/L augmenting the header, which would be a forwards compatible 
change that leaves us leeway to use anything we want to convey versioning info.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to