Is your feature request related to a problem? Please describe.
Whether a tuning heuristic applies often depends on a version, and today each one answers that question inline. AutoTuner.scala holds five such comparisons across two unrelated dimensions: a plugin-version gate for concurrentGpuTasks (line 769, against pluginVersionAutoConcurrentGpuTasks = 25.06.0), and Spark-version gates at lines 842-845 and 2778-2779.
This has three costs. The applicability rule is invisible from the outside, so nothing lists which heuristics are conditional or on what. The plugin dimension is the one that will grow, because a heuristic that consumes a new plugin metric is only valid for versions that emit it, so each unreleased feature adds another comparison. And the gate is entangled with the recommendation it guards, so changing the policy means editing the calculation, as issue #2104 found: a proposed support-policy change there could not be made without inverting the existing test at ProfilingAutoTunerSuite.scala:1586, whose fixture is a 25.04.0 jar.
Describe the solution you'd like
Let a heuristic declare its minimum plugin version, and its Spark version range where relevant, as configuration rather than code, so the tuning layer can skip it on inputs it does not apply to. tuningConfigs.yaml already carries per-property tuning entries and is the natural home. The applicable set then becomes inspectable and testable on its own, separately from whether each recommendation computes the right number.
Describe alternatives you've considered
Leaving it as is, which is defensible while the count is low; the plugin dimension has exactly one instance today.
Gating on evidence instead of version, which works when a heuristic depends on a metric that older plugins do not emit, since absent evidence is itself a version signal. #2104 expects to use this. It does not generalize: a heuristic whose applicability turns on changed runtime behavior rather than a new metric has no such proxy.
Additional context
Raised while reviewing the #2104 design, and deliberately kept out of it. Not urgent, and worth revisiting when a second plugin-version gate appears. Unmeasured: no assessment yet of how much of the existing conditional logic actually fits a declarative form.
Is your feature request related to a problem? Please describe.
Whether a tuning heuristic applies often depends on a version, and today each one answers that question inline.
AutoTuner.scalaholds five such comparisons across two unrelated dimensions: a plugin-version gate forconcurrentGpuTasks(line 769, againstpluginVersionAutoConcurrentGpuTasks=25.06.0), and Spark-version gates at lines 842-845 and 2778-2779.This has three costs. The applicability rule is invisible from the outside, so nothing lists which heuristics are conditional or on what. The plugin dimension is the one that will grow, because a heuristic that consumes a new plugin metric is only valid for versions that emit it, so each unreleased feature adds another comparison. And the gate is entangled with the recommendation it guards, so changing the policy means editing the calculation, as issue #2104 found: a proposed support-policy change there could not be made without inverting the existing test at
ProfilingAutoTunerSuite.scala:1586, whose fixture is a25.04.0jar.Describe the solution you'd like
Let a heuristic declare its minimum plugin version, and its Spark version range where relevant, as configuration rather than code, so the tuning layer can skip it on inputs it does not apply to.
tuningConfigs.yamlalready carries per-property tuning entries and is the natural home. The applicable set then becomes inspectable and testable on its own, separately from whether each recommendation computes the right number.Describe alternatives you've considered
Leaving it as is, which is defensible while the count is low; the plugin dimension has exactly one instance today.
Gating on evidence instead of version, which works when a heuristic depends on a metric that older plugins do not emit, since absent evidence is itself a version signal. #2104 expects to use this. It does not generalize: a heuristic whose applicability turns on changed runtime behavior rather than a new metric has no such proxy.
Additional context
Raised while reviewing the #2104 design, and deliberately kept out of it. Not urgent, and worth revisiting when a second plugin-version gate appears. Unmeasured: no assessment yet of how much of the existing conditional logic actually fits a declarative form.