weiqingy commented on issue #1006:
URL: https://github.com/apache/flink-agents/issues/1006#issuecomment-5274129141

   Recording a measurement against the second option above, since it turns out 
not to be implementable today.
   
   Making the default iterate every supported version would fail on its first 
iteration. `runtime` does not compile at 1.20: `test-compile` against 1.20.5 
reports 5 errors, all in 
`runtime/src/test/java/org/apache/flink/agents/runtime/RescalingTest.java` 
(lines 55, 56, 353, 373, 458), which imports 
`org.apache.flink.streaming.api.functions.sink.legacy.SinkFunction` and 
`org.apache.flink.streaming.api.functions.source.legacy.RichParallelSourceFunction`.
 Those packages exist only in Flink 2.x. It is the only file in the repository 
that imports them, and 2.0.2 and 2.2.1 compile clean.
   
   There is a second cost even if that were resolved. The Java unit-test 
modules have no `flink-<version>` profiles, and passing `-Dflink.version=` 
instead is not a substitute: it leaks into the dist modules that share the same 
reactor, flipping `dist/flink-2.2` off its own 2.2.1 pin. So a per-version Java 
unit-test run needs profiles in the root pom, multiplies every job that runs 
the Java unit tests by roughly five, and duplicates coverage the 
`java_it_tests` matrix already provides across all five versions.
   
   So I am taking the first option, with one change of substance. Rather than 
documenting the single default, I would like to derive it from the root pom's 
`flink.version`, so the Java and Python lanes stop disagreeing and the value 
cannot drift again at the next bump. `tools/update_flink_version.sh` already 
reads that property the same way, and it is the drift itself that produced the 
current state, since that script bumps poms and never touches `tools/ut.sh`.
   
   A bare `tools/ut.sh` would then run both lanes on 2.3.0 rather than Java on 
2.3.0 and Python on 2.2.x. The only CI job whose behavior changes is the one 
running `tools/ut.sh -p`, which moves to PyFlink 2.3.0. Both integration 
matrices pass `-e -f` explicitly and are untouched.
   
   PR shortly. Happy to fall back to a plain documentation fix if you would 
rather the default stayed pinned to a literal.
   


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