How does MAGI handle versioning of ai-script instructions? #2
Replies: 5 comments
-
|
We had the same concern at my previous team. What we ended up doing was treating the Would love to see MAGI add an optional |
Beta Was this translation helpful? Give feedback.
-
|
Both good approaches. I think the hint-based approach makes the most sense for MAGI since the format is designed to be durable. Having the processor resolve model availability at runtime keeps the .mda files from going stale. @adoniyahbobay26 the |
Beta Was this translation helpful? Give feedback.
-
|
This is a great question — I've been thinking about this too for a project where we're iterating on prompts frequently. One approach I've been considering is adding a {
"script-id": "summarizer-v2",
"version": "2.1.0",
"prompt": "..."
}Then the processing pipeline could maintain a mapping of Does the spec have any plans for a formal versioning mechanism, or is this something the community should propose? |
Beta Was this translation helpful? Give feedback.
-
|
Curious if there's tooling in the works for |
Beta Was this translation helpful? Give feedback.
-
|
We treat ai-script semver as a hard contract — minor bumps are additive, majors require explicit migration. Same approach as protobuf has worked for years. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I'm integrating MAGI into our document pipeline and wondering about forward compatibility. If the ai-script schema evolves (e.g., new fields are added or
providervalues change), how should we handle versioning?For example, if I write an ai-script block targeting
gpt-4otoday and the model gets deprecated, does MAGI have a recommended fallback pattern? Or is there a version field planned for the ai-script schema itself?Beta Was this translation helpful? Give feedback.
All reactions