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
docs: update version-aware proposal with design decisions
Resolve open questions based on feedback:
- YAML as source of truth for the version feature registry
- Fine-grained per-capability granularity (OQL functions, DB connector
features, REST enhancements tracked individually per minor release)
- SHOW FEATURES works without a project (FOR VERSION 10.24 syntax)
- SHOW UPGRADE OPPORTUNITIES analyzes current project for improvable
patterns
- Minor version granularity by default
- Non-interactive upgrade advisor (lint --upgrade-hints)
Expanded the YAML example to show per-capability entries across all
areas (OQL functions, microflow activities, page features, integration).
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
BSON Layer Schema Registry "How do I serialize this?"
369
488
```
370
489
371
-
## Open Questions
490
+
## Design Decisions
372
491
373
-
1.**YAML vs JSON for registry?**YAML is more readable for humans editing it; JSON is easier to parse. Could use YAML as source, compile to embedded JSON at build time.
492
+
1.**YAML as source of truth.**Human-readable, easy to edit, reviewed in PRs. Compiled to embedded Go structs at build time via `go:embed` + YAML parser.
374
493
375
-
2.**Granularity of features?** Per-statement (`CREATE VIEW ENTITY`), per-property (`Params:` on pages), or per-concept (`view_entities`)? Probably per-concept with per-property notes.
494
+
2.**Fine-grained features.** Mendix adds capabilities per minor release across all areas (new OQL functions, database connector features, REST enhancements, page properties). The registry must track at the **per-capability** level, not just per-concept. Example: `oql_functions.string_length` introduced in 10.8, `oql_functions.date_diff` in 10.12, `rest_client.query_parameters` in 11.0. Grouping by area with individual capability entries:
495
+
496
+
```yaml
497
+
oql_functions:
498
+
string_length: { introduced: "10.8" }
499
+
date_diff: { introduced: "10.12" }
500
+
coalesce: { introduced: "10.14" }
501
+
database_connector:
502
+
basic_query: { introduced: "10.6" }
503
+
parameterized_query: { introduced: "10.12" }
504
+
runtime_connection: { introduced: "11.0" }
505
+
```
376
506
377
-
3.**Should SHOW FEATURES work without a connected project?**Could accept `SHOW FEATURES FOR VERSION 10.24`without needing an MPR file. Useful for planning.
507
+
3. **SHOW FEATURES works without a project.** `SHOW FEATURES FOR VERSION 10.24` queries the registry directly without an MPR connection. When connected, it defaults to the project's version. Useful for upgrade planning: `SHOW FEATURES ADDED SINCE 10.24` shows what upgrading to the latest would gain; `SHOW FEATURES FOR VERSION 11.6` shows the full capability set of a target version. When connected, also supports: `SHOW UPGRADE OPPORTUNITIES` to identify patterns in the current project that could benefit from the project's own version capabilities (e.g., detecting workarounds that are no longer needed).
378
508
379
-
4.**How to handle patch-level differences?**Most changes are at the minor level, but some patch releases introduce fixes. Use minor as the default, with patch-level overrides where needed.
509
+
4. **Minor version granularity by default.** Metamodel changes happen at the minor release level. Patch-level overrides supported where needed but expected to be rare.
380
510
381
-
5.**Should the upgrade advisor be interactive?**E.g., `mxcli upgrade --from 10.24 --to 11.6 --dry-run` that shows a migration plan and optionally applies changes.
511
+
5. **Non-interactive upgrade advisor for now.** `mxcli lint --upgrade-hints --target-version 11.6` outputs a report. Interactive `mxcli upgrade` can be added later as the tooling matures.
0 commit comments