prototype: backwards-compatible aliases for renamed variable keys

[suhaslord]

Purpose

Fork-only staging PR for the small compatibility idea separated from OpenMDAO#1277. This is not an upstream submission.

Scope

• add a tiny legacy-name → canonical-name map
• normalize legacy CSV headers at the existing input parsing boundary
• immediately store/use the canonical variable name
• add focused coverage for an older mission:constraints:max_mach CSV header

Explicitly not included

• no migration script
• no custom GitHub workflow
• no migration manifest
• no repository-wide rewrite
• no changes to the already-merged MAX_MACH implementation from MAX_MACH update OpenMDAO/Aviary#1250

Upstream Discussion draft

Title: Proposal: backwards-compatible aliases for renamed Aviary variable keys

Following the MAX_MACH rename in OpenMDAO#1250, I wanted to separate one small idea from the broader tooling I had included in OpenMDAO#1277.

The question is whether Aviary should provide a lightweight compatibility path when a serialized/user-facing variable name is renamed. For example, an older input file may still contain mission:constraints:max_mach after the canonical variable becomes aircraft:design:max_mach.

Aviary already has alias support in read_data_file(), so I don't think this needs a repository migration script, custom workflow, or migration manifest.

My proposed scope would be:

• maintain a small mapping from supported legacy input names to canonical variables
• resolve aliases only at the input/file parsing boundary
• immediately store/use the canonical variable name internally
• optionally emit a deprecation warning when an old name is encountered
• add focused coverage showing an older CSV still loads into the canonical variable

I would not include the migration script, migration workflow, repository-wide audit, or other tooling from OpenMDAO#1277.

I have a small fork-only prototype to validate the shape of the idea, but I won't open another upstream PR unless the maintainers think this behavior is useful and agree on where the compatibility mapping should live.

Would this kind of compatibility behavior be useful for Aviary? If so, would you prefer the alias information to live with variable metadata, in the existing data-file utilities, or somewhere else?

Status

Prototype is intentionally kept on the fork while this is proposed in GitHub Discussions, as requested by Jason on OpenMDAO#1277. No upstream PR should be opened before maintainers respond.