stevenzwu commented on code in PR #16677:
URL: https://github.com/apache/iceberg/pull/16677#discussion_r3358556128
##########
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;
+
public static final List<Integer> ALL_VERSIONS =
- IntStream.rangeClosed(1,
MAX_FORMAT_VERSION).boxed().collect(Collectors.toUnmodifiableList());
+ IntStream.rangeClosed(1, MAX_PRODUCTION_VERSION)
Review Comment:
Workable but the migration cost is significant. The three constants are
referenced by 68 test files directly and another 89 files inherit from one of
the four core bases that use them (`TestBase`, `DeleteFileIndexTestBase`,
`PartitionStatsHandlerTestBase`, `ScanPlanningAndReportingTestBase`) — 157
distinct test classes total, spanning core, spark, flink, data, kafka-connect,
parquet, orc, and api.
Opt-in switching means flipping each of those (or at minimum the four base
classes) to `UP_TO_V3` to preserve today's "no v4 in default coverage" state.
That's a wide diff up front, and a similarly wide diff later when v4 is ready
and the goal is to get them back on `ALL_VERSIONS`.
The default-lag approach in this PR keeps both endpoints cheap — one-line
gate today, one-line revert when v4 read/write covers everything the
parameterized suite exercises. The comment on the constant flags it as a
transient scaffold so it doesn't outlive its purpose.
`UP_TO_V3` could still be added alongside as an opt-in for new tests that
want to pin coverage explicitly; that's purely additive and works with either
approach.
--
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]
