You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It became too easy to miss shims due to different explicit lists maintained for different type of shims. E.g., see #10465, #11052
This is due to the complexity of maintaining the shim lists manually stemming from:
Number of Shims
Explicit list of snapshot vs noSnapshot
Upstream vs Vendor Shims
Subset of shims such as Upstream [3.3, 4.0) released for Scala 2.12 and Scala 2.13
Subset of shims such future 4.0 released just for Scala 2.13
All vendor shims just for Scala 2.12
It is clear that this is getting out of control even with the approaching cut of Spark 3.1.x shims per #10955
This issue proposes to generate these lists from a single source of truth instead of manually updating multiple lists. Each new shim requires a profile in the pom, thus the list of such profiles is a natural choice to be a single source of truth.
Describe the bug
It became too easy to miss shims due to different explicit lists maintained for different type of shims. E.g., see #10465, #11052
This is due to the complexity of maintaining the shim lists manually stemming from:
It is clear that this is getting out of control even with the approaching cut of Spark 3.1.x shims per #10955
This issue proposes to generate these lists from a single source of truth instead of manually updating multiple lists. Each new shim requires a profile in the pom, thus the list of such profiles is a natural choice to be a single source of truth.
So all.buildvers can be obtained via
We can iterate through this list and easily determine whether it points to a SNAPSHOT or not instead of maintaining lists (no)Snapshot.buildvers
We also have a deterministic convention for Databricks profiles
As for for Scala we have a relatively simple set of rules to code
The text was updated successfully, but these errors were encountered: