Our schema validation is strict. When we add fields to the schema, files that contain them will not be usable in older versions of the publisher. Extension auto-updates mitigate the issue, but they're not always enabled. We need a strategy to deal with this.
Some ideas:
Do nothing - if you're collaborating with or deploying content created by someone using a newer extension, you need to update. You can work around new fields by dealing with them manually, for example, by removing them.
Allow extra fields and preserve them when writing config files. This means that field name typos won't be errors (we could warn). Any new deployment features called out in the config file won't be applied as specified, because the older client doesn't understand those fields.
If the publisher sees a schema that is not built-in, load it from the schema URL and use that for validation. We would also need to preserve the extra values as above.
The strategy might be different for configurations (user opts in to using new fields, and expects them to be honored) vs. content records (Publisher creates them and decides what information to include).
Our schema validation is strict. When we add fields to the schema, files that contain them will not be usable in older versions of the publisher. Extension auto-updates mitigate the issue, but they're not always enabled. We need a strategy to deal with this.
Some ideas:
The strategy might be different for configurations (user opts in to using new fields, and expects them to be honored) vs. content records (Publisher creates them and decides what information to include).