Motivation

This PR introduces explicit schema versioning for metrics definitions.
The goal is to make telemetry changes safer and more maintainable:

• enabling easier debugging and auditability of metric changes over time
• makes it easier to analyze data across schema versions by maintaining backward compatibility

For now:.

• No persistent file or central registry to verify schema consistency
• No strict validation

However, having the schema_version available in Tinybird helps with:

• Managing backward compatibility.
• Reconciling metrics whose schema may have evolved over time.
  • For example, suppose an initial version of a counter uses label_1_value to store the status of a request, with possible values like "success" and "error". Later, the counter is updated: a new label label_2 is introduced to hold the status instead:

multiIf(
      schema_version = 1, label_1_value,
      schema_version = 2, label_6_value,
      schema_version = 3, label_*_value,
      ...
  ) AS status

A more structured approach would require:

• A schema registry.
• Explicit contracts for each metric.
• Validation at build time, CI, or runtime to ensure consistency between contracts and the metric definitions in code.

Changes

• Introduced a naive approach for handling schema_version in metrics.