How should evaluation evidence be versioned across ADK 1.x and 2.0?

[yuehua1213]

ADK 2.0 introduces breaking changes to the agent API, event model, and session schema, while sessions have a specific compatibility boundary with 1.28+ and older 1.x versions. That makes versioned behavioral evidence especially important: a sample or agent may still load while producing different events, state transitions, or workflow behavior.

For teams evaluating reusable agents and workflows, it would help to bind each result to the ADK version, model, tools, session schema, task, observed output, failures, and environment.

Is there a recommended way to persist and compare evaluation evidence across the 1.x → 2.0 boundary, particularly for workflow routing and task delegation?

[Humerous]

I would treat the eval case and the execution evidence as two different versioned artifacts.

I don't see a documented ADK cross-major provenance format that makes a 1.x session/event dump directly comparable with a 2.0 one. Given the breaking changes to the agent API, event model, and session schema, I would avoid using the serialized ADK session itself as the comparison contract.

Instead, keep a stable logical eval case and store each execution as an immutable run with explicit provenance.

For example:

case_id: delegate_customer_refund
case_version: 3

run:
  adk_version: 2.0.0
  python_version: 3.12.5
  app_git_sha: abc123
  model: gemini-2.5-pro
  model_config_hash: ...
  toolset_version: ...
  environment: staging
  session_schema_family: adk-2

evidence:
  input: ...
  raw_events: ...
  final_output: ...
  failures: ...
  state_checkpoints: ...
  routing:
    - agent: coordinator
    - agent: refund_agent
  delegations:
    - from: coordinator
      to: refund_agent
      task: ...