dramaticlly commented on code in PR #16677:
URL: https://github.com/apache/iceberg/pull/16677#discussion_r3359131375
##########
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:
Fair, my mental model splits the parameterized callers into two buckets:
1. Version-aware tests (e.g. TestFormatVersions, TestMergeAppend):
graduating their coverage from v3 to v4 feels like it should be a deliberate,
reviewable decision. Ideally it shall happen in the same PR that signals "v4
integration concludes for the given test coverage. This also help highlight the
intent to the reviewer.
2. Version-agnostic tests: these read to me as "exercise this against
every format version we ship." If the original contract was "all available
versions," I'd lean toward keeping that contract intact and letting v4 join the
set when it's ready, rather than redefining ALL_VERSIONS and silently dropping
coverage we already have today. The serde round-trip case
`roundTripSerdeV3andHigher` flagged above is a good example.
--
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]
