Harden the Pravega dependency version against external influence

[EronWright]

trafficstars

Problem description Dependency versioning improves stability by explicitly building against the version that the code was designed for. Pravega provides no compatibility guarantees for its client API at this time. The connector build script should resist external influence over the Pravega dependency.

Suggestions for an improvement Eliminate the pravegaVersion variable.

[fpj]

I don't fully understand this issue. It refers to compatibility of the client API, but suggests to remove pravegaVersion. I'd like to understand what the precise problem is that we are trying to solve here and how removing pravegaVersion solves it.

[EronWright]

To elaborate on the issue, the pravegaVersion variable exists to centralize the value across numerous locations in the build script. In my opinion it should be considered to have 'private' access (in a Java sense), as opposed to 'public' access as though it were intended to be set by application code. The objective of this issue is make pravegaVersion private.

The rationale is, at any given point in time, the connector depends on specific versions of Flink, Pravega, Guava, etc. The legitimate ways to change the version of a dependency are to: a) update the connector with a new commit (with any necessary code changes) b) rely on dependency resolution strategies in the application's build script (e.g. Gradle's resolution strategies).

The current situation is problematic because some build jobs attempt to override pravegaVersion to be equal to the server version, which is not a practical approach and leads to false bug reports.