added v12_10 xsd files

[nickcarenza]

No description provided.

[mike-marcacci]

This looks solid to me! I do want to note that this needs to be a major release since we're changing the default, and that's fine with me.

[nickcarenza]

What do you think about matching their versions? So going straight to 12.10.

[mike-marcacci]

I have mixed feelings about that as a general strategy. Semver is super useful when describing changes to a single interface, but much less suited for situations with complex interdependencies.

For example, moving from their API v11 to v12 might change our API in a backwards-incompatible way, which is great: bump from v11.x.x to v12.0.0. However, if we then realize the need to make a breaking change in our API, we would have to either break the version coordination and release v13.0.0 that still corresponds to their v12 API, or wait until they release v13 so we can introduce our breaking change.

All that said, I don't expect a lot of changes here, so I'd be OK trying to keep them coordinated – it's certainly much easier to follow whey coordination is possible.

[nickcarenza]

Interesting point. I hadn't thought about that case. If we're not going to do that then it might make sense to also not change the default version as a general strategy. It might even make sense to push a new major this time where we make version a required config param with no default. A default hardly makes sense anyways since there are many valid versions of the API.

[sonarcloud]

Quality Gate failed

Failed conditions
14 Security Hotspots
30.4% Duplication on New Code (required ≤ 3%)

See analysis details on SonarCloud