Repository navigation
Deprecation of Outputs #300
Description
After releasing GPEC v2.0.0, we'll need to have a robust method for deprecating parameters while preserving backwards compatibility (https://semver.org/). #217 contains an initial attempt at this by just removed deprecated inputs from the toml parsing, but I think we need something more robust.
For example, that example uses mer_flag - but the actual implementation should take mer_flag and probably include more complicated logic to use it to fill local_stability_flag.
TBD on what the best way to do this is right now, open to suggestions.
Activity
logan-nc commentedon Jun 23, 2026
Tagging @matt-pharr on this
@matt-pharr, I believe we want this before v2.0.0 right? So we aren't scrambling/rushing when someone changes a toml post-release (which they will inevitably do right away).
logan-nc commentedon Jun 23, 2026
@jhalpern30 I think this connects to #139 (and maybe another issue?). Basically, we should break up structs into ones that correspond one to one with the static toml settings and other things like splines and solutions and other things that might change instead of big globals type structs. Once we do this one-to-one struct, I there must be a way to compare the toml dict to the struct keys and drop any toml keys not in the corresponding struct keys.
logan-nc commentedon Oct 27, 2026
#569 settles the mechanism: a deck or a replayed gpec.h5 that sets a retired key now stops with the key named, the lists live in one place in the driver, and a pre-commit hook keeps the example decks clean. What it deliberately does not do is the mapping this issue sketches (
mer_flag→ the new section); the maintainers chose a hard stop over silent translation. Suggest closing when #569 merges, or re-titling to the narrower question of whether any retired key deserves a translation rather than a stop.