Version aware MDL script

[ako]

To enable to correct execution of the example MDL scripts on different version i've introduced a version annotation. This allows you to run MDL statements only on specific versions.

-- @Version: 10.18+
-- @Version: 11.0+
-- @Version: any

See for example: https://github.com/mendixlabs/mxcli/blob/main/mdl-examples/doctype-tests/01-domain-model-examples.mdl

This proposal describes how we can add version awareness for coding agents: https://github.com/mendixlabs/mxcli/blob/main/docs/11-proposals/PROPOSAL_version_aware_agent_support.md

[boerpb]

One thing worth considering: the Mendix Content API already solves a very similar version-availability problem for Marketplace add-ons. Each component release carries a minimum (and sometimes maximum) Studio Pro version, and Studio Pro uses that metadata to resolve the highest compatible release at download time. The conceptual model is the same — mapping capabilities to version ranges — just applied to external packages rather than internal platform features.

The proposal currently mixes introduced: "10.18" with available_in: "11.0+" and null for "not in this major" in a way that's somewhat ad-hoc. I'd suggest aligning the version range syntax with what the Marketplace already uses: explicit min_version / max_version bounds using consistent semver-style notation. This way a single version-comparison implementation handles both "is this Marketplace module compatible with my project?" and "is this platform feature available in my project?" — which matters particularly for agents that need to reason about both in the same session (e.g. creating entities and importing a module).

To be clear: I'm not suggesting adopting the Marketplace's full data model (component → releases → packages). The per-feature YAML registry is the right abstraction for platform capabilities. The alignment is specifically about the version bound format and comparison semantics.

Concretely, something like:

view_entities:
  min_version: "10.18.0"
  mdl: "CREATE VIEW ENTITY Module.Name (...) AS SELECT ..."
  notes: "OQL stored inline on OqlViewEntitySource"

page_parameters:
  min_version: "11.0.0"
  workaround:
    description: "Pass data via a non-persistent entity"
    max_version: "10.99.99"

rather than the current mix of introduced, available_in, and null.

It would also be worth explicitly referencing the Content API's versioning conventions as prior art in the proposal doc itself — even if you decide to diverge, making that a conscious and documented decision prevents a future contributor from accidentally introducing a third versioning format into the ecosystem.

Small additional thought on open question #2 (granularity): per-concept with per-property overrides seems right, and it mirrors how the Marketplace handles it — a module has one compatibility range, but release notes can call out property-level changes. The registry could follow the same pattern: feature-level min_version with optional property-level overrides where needed.