wombatu-kun commented on code in PR #16677:
URL: https://github.com/apache/iceberg/pull/16677#discussion_r3353053375


##########
api/src/test/java/org/apache/iceberg/TestHelpers.java:
##########
@@ -74,12 +74,26 @@ public static <T> Stream<Arguments> serializers() {
   private TestHelpers() {}
 
   public static final int MAX_FORMAT_VERSION = 4;
+
+  // The highest format version covered by the default version-parameterized 
test ranges below.
+  // While a new format version is being incubated, this lags 
MAX_FORMAT_VERSION so that the
+  // existing parameterized test suite is not pinned to an incomplete code 
path. Bump this to
+  // MAX_FORMAT_VERSION when the incubating version's read/write code paths 
cover every feature
+  // exercised by the parameterized suite.
+  public static final int MAX_PRODUCTION_VERSION = 3;

Review Comment:
   My vote is `DEFAULT_MAX_TEST_FORMAT_VERSION`. It stays parallel with the 
sibling `MAX_FORMAT_VERSION` (keeps the `_FORMAT_VERSION` suffix), and 
`DEFAULT` reads naturally as "the default upper bound for these ranges, which 
explicit v4 tests can still opt past."
   
   I'd lean away from `MAX_PRODUCTION_VERSION` / `MAX_STABLE_FORMAT_VERSION`: 
sitting next to core's `TableMetadata.SUPPORTED_TABLE_FORMAT_VERSION = 4`, a 
"production/stable = 3" constant reads like a product-level claim about what 
Iceberg ships rather than a test-suite knob.
   
   `MAX_PARAMETERIZED_TEST_FORMAT_VERSION` is also fine and very explicit, but 
a few consumers iterate the ranges in plain `for` loops / `assumeThat(...)` 
guards (e.g. `TestSparkMetadataColumns`, `TestFlinkUpsert`, 
`TestScansAndSchemaEvolution`) rather than via `@FieldSource`, so 
"parameterized" slightly undersells the scope. 
`DEFAULT_MAX_TEST_FORMAT_VERSION` avoids that.



-- 
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]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to